Bitcoin Forum

Last night, randy-waterhouse and I were experimenting with Bitmessage. (*smooch*!!)

Bitmessage is a p2p messaging (and broadcast / subscription) protocol, based on the Bitcoin protocol.

It uses its own blockchain, but the chain only stores the last 2 or 3 days worth of messages. (It's assumed they were delivered within that time, where they are then safely stored on the recipient's inbox.)

Combining the above Bitmessage capabilities--which we already proved out experimentally--with Open-Transactions, makes possible fully-decentralized p2p markets, as well as p2p escrow across OT federated servers, easy p2p and server-to-server wiring of funds and conversion of currencies, both within OT and also between OT and the conventional banking system.

Furthermore, this is possible with little-to-no changes inside OT itself, and will not require the issuing of credit, nor will it require any pre-mined currency.

How does it work?

-----------------------------------------------------------

A few concepts...

--- First, keep in mind the concept that Bitcoins and Colored Coins (either/both) could be issued onto an OT server, without having to trust the server itself, through the use the multi-sig "voting pools" on the blockchain itself. I've already extensively discussed this on this board, and here's an article on how it's done:  http://bitcoin.stackexchange.com/a/834/309 (http://bitcoin.stackexchange.com/a/834/309)

--- Second, keep in mind that using Colored Coins instead of Bitcoins is advantageous in certain circumstances, as it allows users to buy/sell those colored coins (for the purposes of transmitting other currencies) without incurring any capital gains tax liability. (I'm not a lawyer and that's not legal advice. The basic gist is, if you buy a colored coin for $100, and sell it for $100, there is obviously no gain or loss.)

-----------------------------------------------------------

T H E   H O L Y   G R A I L

Enter Bitmessage! (Which solves discovery across federated OT servers.)

As I said, randy-waterhouse and I already TESTED Bitmessage last night to prove experimentally that this is possible (and it worked.)

-----------------------------------------------------------

Using Bitmessage with OT to effect server-to-server wiring of funds: http://pastebin.com/NjQgDarx (http://pastebin.com/NjQgDarx)

--- The wiring protocol is all about Alice trying to discover Bob so she can move her money from one server to another (and Bob trying to discover Alice so he can make a profit by moving money from one server to another.)

-----------------------------------------------------------

Using Bitmessage with OT to effect escrow-based conversion of currencies across OT federated servers:  http://pastebin.com/S1W5guAQ (http://pastebin.com/S1W5guAQ)

--- The currency conversion protocol is about Alice and Bob being able to choose a server they can agree to meet on so they can trade one currency for another inside OT. (For cases where they aren't already trading on the same OT server.)

-----------------------------------------------------------

Using Bitmessage with OT and SEPA so that Alice can p2p send any currency which Bob receives as Euros in his Euro account: http://pastebin.com/SsLrxVP6 (http://pastebin.com/SsLrxVP6)

--- The SEPA transfer protocol is about Alice being able to send Silver Grams, which Bob receives as Euros in his Euro bank account. It's also about Jorg earning a profit in silver grams, by sending a SEPA transfer to Bob on Alice's behalf.

-----------------------------------------------------------

We already knew that OT offered quite a few benefits to Bitcoin: http://bitcoin.stackexchange.com/a/2710/309 (http://bitcoin.stackexchange.com/a/2710/309)

But now, combined with Bitmessage, Open-Transactions becomes a juggernaut!

The above protocols can be implemented inside OT wallet GUIs, such that they are automated and transparent to users.

May a million currencies bloom!

I do not believe bitmessage uses a blockchain currently (it didn't when I looked at it before, and with a quick glance that doesn't seem to have changed).

A blockchain (and the resulting ~global consistency) isn't needed for traffic analysis resistant anonymous communication ... though it does have an effect of creating some unjammability.  I don't think bitmessage has unjammability esp for widely known keys.  I think unjammability is important for OT's usage here.

Am I confused?

Most of the capabilities were already latent in OT. Bitmessage is just what solves discovery.

(In fact you could swap it out for any similar solution which solves discovery.)

Whoa ... is this what I think it is, blueprint for P2P exchange?

Yes.

uuh! I really like to see some evolvement on this :D (and I'm already a fan of Bitmessage!)

This does sound like it's a big o,O Is it?

Ahh.  Brilliant.  I'm still looking at it in detail, but this looks incredible!

It's the last piece of the puzzle:  the link between all currencies.

Oh - and the end of Ripple.  Rest In Pieces.   :-*

This is a little over my blond head.  I am assuming OP is excited because this means easier transfer of BTC peer to peer without the long wait for blockchain verification?  Can someone dumb this down for me?  THX

Nice, I will have to check more into Bitmessage.

Does it require a client on your machine, or can it be done online?

I would like to suggest that they change the name if this will indeed become a successful P2P exchange. Perhaps a more interesting name would be beneficial later on when people wonder what it is.

The name is "Open-Transactions."

The above protocols use Bitmessage for the discovery layer, but any other discovery layer could also be swapped in.

Wow. Just wow.

This is the start of something big.

I don't really understand it yet but I can recognise a revolution when I see one.

Great, I just want to make sure we iron out any new potential complications relating to Bitcoin projects. I hope this projects goes well, if I can contribute any design content(Free of charge) I will. :)

Economic technology is now one step closer to singularity.

Wow, not sure if this means what I think it means, but after checking out open transactions, I have a feeling it means the end of the not so open Ripple idea.

Fantastic!

One thing I'm curious about is the propagation and validation. With the transaction notification being passed through bitmessage, acceptance is still dependent upon the receiver, correct? Txs therefore can be instantaneous, but might also incur a variable delay?

This really looks like a promising idea. Will be following closely.

Just learned about Bitmessage. I suggest people go read the white paper on their wiki - short and to the point. It has the potential to upset email because of the increased privacy, built-in mailing-list functionality, and anti-spam measures (proof of work makes it hard to create lots of messages fast). This Open Transaction use case is a perfect example of the innovation possible with it.

Out of curiosity if this was to gain momentum what would it mean for traditional Bitcoin exchanges? I am curious as today I just started working on a new UK exchange (small scale).

* I will be back on tomorow to read the paper too *  ;D

best of luck on this.

i have some studying to do.

Ditto.

While I love the idea of BitMessage, it has never worked when I've tried it. Me or my counter-parties never received the messages we sent.

If/when it starts to work as it it's supposed, it has the potential to become an important tool alongside Bitcoin for decentralized and pseudonymized transactions.

Quick, someone snap a picture of Jonathan Warren before he disappears forever...

Fellowtraveler, this is very exciting. I've been reading your OT stuff for a while and trying to absorb it all. Are you or your new company going to take OT now and develop it into this P2P exchange application? I think you should because it doesn't look like anyone else is ready to produce a product like this. I'm sure you could garner some serious donations if necessary since you've already proven yourself by putting OT together.

There will be tons of opportunities for everyone once this kind infrastructure is in place, so I hope we can all work together on it and keep it open.

What sucks is, surprise, the completely anachronistic banking system. Had banks digitally signed transactions like SEPA transfers, the dispute resolution could have been much easier.

How does this enable wiring of funds and conversion of currencies between OT and the conventional banking system?

So bitmessage is essentially snapchat (i think, i dont use it) plus encryption. My cryptosense isn't particularly adept, but the bit about 'passive operating mode' seems too much like "security through obscurity" rather than security through mathematics (sending parts of message/acks through other paths to obscure a communication channel). Not that this matters much on the replacement-of-email level, but on a currency exchange level it makes all the difference in the world.

Currently accepting any explanations that will help me -> :o

i am wondering about this too.

perhaps fellowtraveler could take us thru an example of how to convert BTC to USD and the exact steps involved.

Yeah I would like a process walkthrough to understand this better.

I suspect this relates to a discussion waxwing and I were having on another thread, cypherdoc.

Integrating knowledge of SEPA and ACH into the software doesn't appear to be that difficult.  Software-driven settlement on the network through ACH/SEPA becomes feasible.  (And yeah - you'd want any account that was OT-enabled to be completely isolated from your normal banking structure, obviously)

The big problem hasn't been settlement within a single currency - it's been settlement across different currencies - that is, cutting out the currency exchange vigorish and regulatory structure.  And this looks like a solution.

But, like you, I have some studying to do.  I'm optimistic though.

Process as per http://pastebin.com/SsLrxVP6. If I'm reading it right, Jorg has USD he's offering to put in Alice's nominated account (which might be her own or might be someone elses) and is willing to accept her BTC in exchange - the bitmessage is involved in the discovery process by which Alice and Jorg can meet in a distributed market. Alice sends BTC, Jorg wires USD to the other account.

If Alice wanted to send as Shekels, or Pesos, the discovery process finds someone who has those and wants to sell them, and presumably is located within that jurisdiction. Indeed if Alice has Russian Roubles and wants to pay a bill in South African Rand and doesn't have BTC at all then she could still do in two goes: discover someone who wants BTC in return for Rand: they provide a BTC address, she provides the South African bank details. Then she finds someone who offers BTC in return for Roubles -- she provides the BTC address from the first guy, he provides his bank account details. She pays in at the cashiers desk, he sends the BTC, the South African receives them and pays the bill denominated in Rand. (Obviously matters of escrow also, dealt with in the pastebin linked above.)

Arbitrary person-to- arbitrary person fiat A to fiat B transfer, no international aspect, "below the radar" in both source and destination country.
If I'm reading it right, that is

That's why I said the banking system is archaic by not providing cryptographically signed transaction receipt, to facilitate the whole process.

"Anachronistic" might be even more accurate: they could have done it if it suited their purposes to do so, but instead time has passed them by.

That's the word I used initially. ;)

I have been looking for something like this! Awesome!

Sounds like a far superior alternative to Ripple. One that the community can get behind.

Whoa...

so, in theory, you can have a zero balance bank account and whenever you go to buy something you load your debit card with just enough to pay the bill by paying with Bitcoins...correct?

And someone can just write up a program to quickly exchange dollars for bitcoins just for that purpose...

Bitcoin debit card...


Or is there still a delay?

What's the important difference with Ripple?
It still seems to be IOUs.

No sketchy pre-mined 100 billion XRP non-currency (currency)?

Well sure, OT doesn't need them, there doesn't seem to be a "network" per se.
(You can't spam the network.)

---> As far as I understand. I'm still in my bitmessage/Open Transactions reading.

Hello FL! Nice to see you here too!

Reading through it, it looks like a huge difference is the absence of XRP facility. Bitmessages handle spamming by adding a proof-of-work load to a computer sending an outbound message, and having a great many possible recipient addresses for an individual all of which respond normally, but actually silently drop the spam. The whitepaper includes additional suggestions for handling it.

Ok, so the point of bitmessage is to be the network, while Open Transaction is the notary.

Correct?

I'm still reading up OT but you're right about BM

Duuuuude! Holy shit! I only got OP when you explained it to me at the Tradehill thing, but this just takes it to a whole other level! Doesn't this basically allow for "Ripple," but in a fully decentralized way, and without XRP?

Bitmessage should allow for communication to create an updated and shared 'order book' across OT server users, if I understand correctly. Although the 'order book' would include all types of transactions, not just currency conversions.

this is a very good thing.

Meanwhile at Tradefortess' house......














http://allthingsordinary.se/images/original/712__0e1ccf61da9a698849c5288ac39759e73c774304_m.gif?1268887090

what's interesting is that in the Angels Meeting on Sunday i brought up BitMessage as an investment idea.  i've been following them for a while and planning on trying it out but wanted to get more feedback from users.  i think they have a brilliant idea as pgp is too hard for most ppl.

anyone have some good experiences?

This is awesome.  Goodbye Ripple!!!

 :o subscribing

What Open Transaction is trying to do is to provide a transfer mechanism, rather than issuing a currency, they use the word "cash" in this sense. If you want to hide your Bitcoin transfer, you can choose to use an OT server, which provably cannot see the link between two accounts involved in a transaction. As it's said in their FAQ, OT server merely provides receipt to be used as evidence, any redemption is between the users.

The difference with Ripple: it's open source, its author is very honest about everything(centralized as federated servers), it doesn't have a premined currency(no currency has a special status in the system), and it serves a purpose(anonymity).

EDIT: OP also proposed that, with Bitcoin's multi-sig escrowing, whenever an OT server signs something it can always be checked if it has enough reserve to back it up.  to quote OP from here: http://bitcoin.stackexchange.com/questions/517/how-can-a-single-person-operation-keep-a-collection-of-online-wallets-secure/834#834


and:


So unlike a RIpple IOU, a open transaction cash token can be backed up.

Fellowtraveler-- if you're willing to do some hand-holding I'd be really interested in making a Chaumian cash transaction through an OT server.

I only ever understand about 30% of your posts.  It doesn't make sense to me how Bitmessage could possibly be a missing link for OT, but I'd rather just go through the motions of making a few transactions and see how it works.

PM me

If this works, this is a huge deal.

Yes. I have been using them for a few weeks, and they seem to be very actively developed, with bugs patched and new features released very quickly. The actual development discussion goes on through BitMessage itself on their general mailing list. It's still missing some features (like organizing messages by sent-date as opposed to when you downloaded them), but it's very very promising. Had a large influx of Chinese users recently, too  ;)

DiThi is planning on using the code for messages within his SecondLife-like virtual world, too, and I imagine it can be adopted for other games and services as well. It's basically a decentralized, serverless, encrypted, private/anonymous P2P messaging system for everything.

me too.

I guess we will also need a few people as multi-sig escrowers, I will volunteer as one of the members of the voting pool.

Say no to drugs! ;D

So, if I understand this correctly...

Bitcoin turns the whole internet into your personal checking/savings account, while BT+OT turns the whole internet into your personal clearinghouse and loan settlement network

Or, said another way:

You use Bitcoin like an equity network, i.e. to store, transmit, and settle value, and BT+OT like a liability network, i.e. to store, transmit, and settle debt.

Is this right?

I like that, it would break the silo there is between real cash and btc.

It's not OP, it's OT......

AFAIK it's not stritcly personal, you need a transaction server, or as OP proposed, something backed by a multi-sig escrowed Bitcoin address with enough reserve which many people act as escrowers, so another user can withdraw his cash(a blind token) and give it to you, to allow you to withdraw from this big money pool. The whole point of OT, at its minimum, is that by using Chaumian blinding, neither the transaction server nor the escrowers can figure out the link between you and the person giving you the token, so the transaction can be carried out anonymously. Based on this form of anonymous transfer of cash, you can build instruments like cheques, IOUs, etc.

It may sound a bit centralized, but in fact its unanonymous form, the mixers, is already widely in use, OT just adds the anonymity to the mixers, in its bare minimum of course.

It's 2:30am. I'm so excited by this I can't sleep. Or apparently think straight  ;D



Can't users run their own servers to issue their own IOUs, too?

This sounds very promising, but we need this like yesterday. How can this be fast-tracked?

Also, can this be used for insurance policies and futures exchange?

Finally, is it just me or do we go back and forth between price surges and innovation? Just a few weeks of price stability and discussion on building stuff seems to have become fascinating again. We humans have a one-track mind, I guess.

Yes, they can, but it has to be a somehow large pool, so you will need to process many tokens(think of it like a bank processing cash withdrawals/deposits) that you can't figure out who gives the token to whom, think about it, if a bankster only ever process cash withdrawals for one person, next time when he receives an identical banknote that he once gave away from another person, he can establish a connection between this person and his old customer, the whole point of unlinkability, and the unregulability as MSB(you can't ask me to record who gives money to whom because I don't know), is defeated.

also, its not BT it's BM.

lets just call it BMOT.

Possible to link to an ATM?(as well)

Agreed. BMOT!



I know why I didn't... reading about the stream stuff, there's no way I would have been able to code that!  :D

I've been watching Open Transactions for the last 3-4 years and I knew there would come a time when it would be used for something. This seems a very effective method of creating a distributed exchange and I approve of it as I see how it could work in theory and in practice. All it would need is to be built so that we could go to a website or series of websites which host the back end. Users probably don't need to know the innerworkings and most users are used to interfacing with the web like with Localbitcoins, MtGox or whatever. Right now Bitmessage is a stand alone python app but it wouldn't take too much effort to turn it into a web app and to turn OT into a sort of back engine and once that happens then it's something which could work.

A Chrome and Firefox extension could work too.

Actually cypherdoc, I think OTBM works better:  "Off Topic Shit"   ;D

 :o

Excellent. Now how long before the XRP bubble pops...

It's not going to replace email. I've been looking at the code and it's not quite the work of art yet but it's more a hobby project. That said it fills an important niche at an important time.

Excellent idea. The ease of use factor should be considered from the start. Bitmessage could even be integrated into forums like these if handled right. Maybe similar to how Bittorrent spread, we'd have to create a .exchange or something similar or a bit:// or something.

Ummm, it is the Open Transactions 'people' that came up with idea to use Bitmessage as secured P2P price/trade discovery mechanism ... which is actually the only part of a fully integrated P2P decentralised exchange that really needs to be P2P ... the settlement is taken care of by the Federation of OT servers (distributed semi-trusted nodes) perhaps localised also ... and potentially strong anonymity off-chain transactions (by notary mechanism only).

But who's counting precedence of ideas eh?  ;)

See, this demonstrates the only thing people dislike about Ripple is that there is a risk it may make their bitcoins and mining rigs worthless. Ripple is more decentralised than OT! I think Bitmessage is great, and I've been running it for a while and advocating greater integration with Bitcoin. All these systems are partially synergetic and partially in competition with each other and both are great. OT can offer real untraceability, just like Zerocoin on top of Bitcoin.

Would love to not turn this into a discussion about Ripple.

+1

Is there a running OT server now?  (I assume there is one owned/operated by monetas.net (http://monetas.net)?)  Are there others out in the wild?  If there are a couple of OT servers and the BM protocol can be established, all we need is an application that combines the two together to get a running P2P exchange, right?

Watching this

I think we really need to push this forward, volunteers? I can be a voting pool escrower or a transaction participator or something else.

Sounds very exciting. But I don't fully understand it yet, I tried to read some material on Open Transactions and BitMessage but still missing the point. Can anyone summarize what it is that OT and BM do, exactly?

Also, imagine a hypothetical world where this has already completely been worked out, and a OT+BM based P2P exchange system is fully up and running. Suppose I want to buy bitcoins with euros. Two questions:

• 1. Where or how do I find someone who wants to sell his BTC, and how do we negotiate a price? (as is currently done by the existing exchanges in their market places)
• 2. Where (or to who) do I wire transfer my EUR, and how can I trust I will get the BTC in return?

I have only a vague understanding, but I think for (1) the answer is Bitmessage, and for (2) it's escrowing(multisig).

Oh man I can't wait for OT to be fully functional and usable and in the limelight and everybody's using it.

https://i.imgur.com/i3tLIPa.gif

To my understanding, OT allows a distributed exchange of currency between two parties (among other things) and BM allows broadcasting of secure/signed messages (among other things).  When BM is combined with OT, there is now a way to have a fully distributed marketplace of buyers and sellers broadcasting bids and asks using BM then transacted using OT.

Uh... I don't see the distributed marketplace. (As most here, I'm still trying to wrap my head around it.)

You would still need to
1. Obtain some kind of IOU (DGC)
2. Trade it at a particular place. (OT server)

http://billstclair.com/ot/ot-diagram.jpg

As far as I get it:

Digital cash token = IOU
Proof-of-work = transaction fee in XRP
OT server = Ripple Gateway
??? = Ripple validators

Also it's not clear what is meant by "Digital Cash instruments are stored on a client side". Should it be some kind of blockchain instead?

You are right, that's why the developer prefers the phrase "federated server".

The reason why it's different from Ripple, is:

1. By trading at an OT server, you can get cash-like untraceability.
2. When the cash token is denominated in bitcoins, you can check if it's sufficiently backed up by a escrowed address, because OT interoperates with the blockchain.

From that pastebin:

"9. Alice's Escrow awakens in 1-5 minutes, and starts periodically checking (via SEPA calls) to see if BOB_SEPA has received the Euros. If so, she automatically releases the Escrow to Jorg's silver account on OT."

This escrow must be able to check the banking transaction via SEPA calls, and I suppose without a formal contract with banks, he won't be able to listen to those calls

Just like a gateway in ripple, this is the point of weakness for all the P2P exchange design: That escrow/gateway must be able to communicate with banks through an authorized channel and that channel is controlled by banks

The core problem is, all of the exchanges today still operate inside a banking framework (the exchange must have a bank account to operate). In order to bypass the existing banking system, there should first be a P2P bank that stores fiat money, that bank could in turn carry its exchange without the involvement of traditional banks

Ah, cool. So here we have a battle of two concepts: Trust (Ripple) vs. Escrow (OT).

THe whole point of using OT is untraceability, it's implemented around the Chaumian blind token technology, if you don't want untraceability, you don't want to use OT.

Can I interpret it like this?

1. By means of BitMessage we can have some P2P market place. I mean "marketplace" just in terms of distributing bid and ask offers throughout anyone interested, not the actual money transactions.

2. Multisig = I can setup some kind of 'combined transaction' with the seller, where I transfer my euros to him, and he transfers his bitcoins to me, and this is effectuated as an atomic transaction (i.e. can't abort or undo half way), and this two-way transaction can only become effective after we both signed it? Or am I completely mistaken?

How does escrowing come into play here?

From my understanding of FellowTraveler's initial post, BM is used for matching Bids and Asks by creating an exchange protocol on top of BM that interested parties can subscribe to.

This is amazing. I was already looking into OpenTransction, but this makes it so much more usable and complete.
Combining these two sounds very promising. Subscribing to this thread.

Pretty much. AFAIK monetas is not running an OT server ... there is actually only 2 alpha that are on-line (but know of at least several others in testing off-line phase) ... server contracts and asset contracts used on the operational gaming TX server "Digitalis" (and Demo server where public can issue assets)  for the Galactic Milieu can be found here

http://sourceforge.net/projects/galacticmilieu/files/ (http://sourceforge.net/projects/galacticmilieu/files/)

See here for fellow traveler's proposal: http://bitcoin.stackexchange.com/questions/517/how-can-a-single-person-operation-keep-a-collection-of-online-wallets-secure/834#834  the escrowing is used to make sure the OT server will not default on its IOU, and you want to trade on an OT server because you want untraceability(that's right, the server operator cannot figure out who are you sending money to, unlike a mixer operator). An OT server also only signs receipts, and do not store any real currency, so in case of a government raid, they will get nothing.

In a traditional bank system, bank A open an account in bank B and bank B open an account in bank A, and they can do transactions both way. But due to bitcoin is not a single entity, traditional banks can open accounts in bitcoin network while bitcoin network can not open a bank account at traditioanl bank, only individuals can

I still think localbitcoins.com is better than the idea of P2P exchange

This is truly amazing!

Ok, let's crowdfund that ;)

I think someone has to call the Winklevoss twins or someone with a lot money and tell them to start a p2p bank :D
Following this Thread, i'm curious about future development!

Drama....


From http://opencoin.org/Members/jhb/opencoin-and-ripple

This won't work. Any bank that starts OT server will be closed for violating AML.

Voucher safe solves this -why don't you people forget the whole cryptos<->fiat thing? It will be a point of failure unless a P2P bank is established (dream on)..

So let's buy a bank in the Virgin Islands.

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 (https://bitcointalk.org/index.php?topic=212841.0)

This won't help either. Even if it's not closed, what's the point in a bank that is banned from dealing within international banking network?

This or commodities to cryptos..

If you reached central banks level, AML is not a concern anymore, all the money is laundered from the central bank at the first place

Probably better to stay on topic, everyone.

I don't think a lot of people realise this but localbitcoins.com is actually a centralised server model ... and does anyone know how much data they retain about all the recorded transactions/messaging that passes through their server? ... wonder which jurisdiction/locale the localbitcoins.com server is located in and what their privacy policy is by the way?

The advantage of OT is just if government raids an OT server, they will get nothing, no store of currency, no meaningful transaction record, no destruction of operator identity(if he remains strictly pseudonymous and uses Tor) , he can just find another server and get online again.

* Solution for the Problem with interfacing into the legacy banking system: *

We simply create our own banking system outside of the legacy banking system bypassing old banks all together.

We as individuals create out own mini-p2p-banks with a small or large safe at home to store cash/silver/gold/whatever.
We build trust by having trusted individuals inspect/audit the mini-banks cash holdings and security on a regular basis.

Each mini-p2p-bank builds security and trust scores as independent private trusted auditors inspect their "banks".

It would be smart to store your money at different banks to protect your wealth against a bank crash.
The mini-p2p-banks handle money transports between themselves.

Since I have been working on this for longer than most on this thread, please let me explain 2 issues:
1> Cash on the barrelhead - WoT system need to assure client that Tx is valid. BM provides this with PoW and OT can reflect the validity on *chain. Unlimited currency/contract/commodity/document.. whatever. Are ya with me?
2> OT can be affiliated with other OT servers through federation but also Trusted computing such as TPM(PAL) -check in Hal's bcflick:
https://bitcointalk.org/index.php?topic=154290
Mike Heath pointed to this solution. Thx

What we are trying to do is square Zooko's triangle:
http://www.aaronsw.com/weblog/squarezooko

The next stage is the watering hole effect - groups acting as agents, not individuals. Pooling resources for clients - not the current free-for-all.

I think you will need a bit more "back to the basics" explanation, a lot here don't even seem to understand an OT server is used to gain untraceability, and compare it to another kind of Ripple.

Can you elaborate on this "untraceability" thing? Why this is so important to have it in OT? Currently, Bitcoin is fully tracebale and no one complains.

Actually, slowing down the uptake with a "back to basics" approach will just invite FUD and trolling. I am trying to move key developers that get it already to include TPM(PAL) in the equation.

And then mini-banks have their assets seized by the feds for violating regulations.

Slowing it down:
- I was looking for Bitcoin before it was created by Satoshi
- I discovered bitcoin in April 2010 while studying Ven/Ripple/Chaumian blinding - came back in December 2010 after surgery(sux) and was please to find it had reached beta/press/attention.
- I was researching complementary WoT systems for a theory of S-curve disruptive technologies - Bitcoin was the prize

TLDR;
I am not trying to talk above people, just to a right-brain populace. Theorists as opposed to engineers.

If you would like to try your hand at an Open-Transactions logo, that would be great.


I'm a fan of the Ripple idea (credit lines) and have always said that I would eventually build it into OT.

(Perhaps sooner rather than later, now that cross-server discovery is solved.)

As for the current Ripple incarnation, I hope their technology proves out and that they are successful.

There is no need to bash people who are trying to contribute to monetary freedom.


--- The transaction notification is used in server-to-server wiring of funds, to unlock the escrow on both sides.
--- The servers can negotiate this between each other directly (since Alice and Bob have notified each server of the other's existence.)
--- In essence, this piece is negotiated directly by the two smart contracts.
--- This doesn't have to go through Bitmessage; that's only used for discovery process.
--- The parties can also directly notice the servers, but this is not necessary for it to work.

> Txs therefore can be instantaneous, but might also incur a variable delay?

I'd say this is accurate, though I would expect it to basically seem instantaneous.


On the commercial side, we have just closed our seed round, and started our second round.
Screenshots of upcoming Monetas iPhone app (http://ft.vm.to/files/screenshots/)

I can say the p2p exchange technology is definitely coming, probably first in some future incarnation of our systray app,  but the timing will depend.

On the open-source side, any donations will be re-donated to various OT contributors for their work.
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ


For specific step-by-step walkthrus of the Bitmessage-related protocols, see the paste bins I posted at the top of this thread.

Here are more details to help clarify...

CURRENCIES

--- Blockchain-based commodities. (BTC, LTC, etc)

Keep in mind: Blockchain-based currencies such as BTC will not have a proper "issuer" on OT; instead they will be uploaded directly by users into voting pools, where an OT server can issue units based on the BTC yet simultaneously are incapable of stealing those BTC. (They cannot steal them from the voting pool because they are protected by multi-sig, and they cannot steal them internally because the OT servers are incapable of forging receipts.)

--- Colored coins. (These are real-world assets such as gold, dollars, pork bellies, etc which are accounted-for using satoshis on the blockchain, and are redeemed by their issuer upon demand.)

Important things to remember about colored coins:

1. The issuer of colored coins can never be held liable to freeze specific satoshis, because they have no control over the ledger (it's on the blockchain.) Which is to say, the colored coins actually do circulate entirely beyond their control. Just as the Federal Reserve issues dollars which then circulate entirely outside of their control, and thus they cannot be held liable for what happens while they are in circulation.

2. This breaks the link on OT between the issuer and the transaction server, since the issuer no longer needs to directly issue their gold onto the OT server. Instead, the issuer uses colored coins, and then those get issued by wallets into voting pools, to make them available for trading on OT servers. This means that pressure against the issuer can never result in withdrawing their currency from an OT server, because they don't have to issue it directly onto an OT server, for people to still trade it there.

3. Most people will not ever need to redeem their colored coins directly with the issuer of those colored coins. As long as the issuer is good for them, they will be able to redeem their colored coins directly through other wallets. So the issuer only provides redemption "of last resort."

4. Anyone who does redeem colored coins at a colored coin issuer, will be subject to the laws in that jurisdiction, AML/KYC, etc. (So there is no need to violate those laws.)

5. Anyone who buys/sells colored coins will not incur capital gains tax risk, since colored coins, unlike BTC, do not go up in value. (Meaning, a $100 colored coin does not change in value between when it was bought and sold, and thus does not incur capital gains. Consult your attorney on that one BTW.)


LEGACY BANKS

--- Transfers to-and-from the legacy banking system are performed via ACH in the USA, and SEPA in Europe.

--- SEPA transfers are instant. ACH transfers can take 3-5 days. Either way, the OT side of such transactions will use OT's ability to perform escrow.

--- Although people will have the ability to go in-and-out of the banking system, I don't expect this to happen with every transaction. I do expect it to happen sometimes.

--- I expect that some of these transfers will happen P2P (SEPA is particularly suited for this) as well as through professional services (probably similar to Ripple gateways.) Any OT Nym could perform such functions.

--- We can automate such things in the wallets, making the actions user-centric, instead of provider-centric.


OPEN-TRANSACTIONS FEDERATED SERVERS

--- Any Nym will be able to upload BTC or Colored Coins into a voting pool (where the OT server cannot steal them) and the OT server then issues the appropriate units to that Nym via OT's unforgeable receipts.

--- The Nyms are already able to perform escrow with each other, on any OT server.

--- The Nyms are already able to trade one currency against another, on any OT server.

--- Already you can have the same currencies issued onto multiple OT servers.


BITMESSAGE

--- Bitmessage makes it possible for Nyms to discover each other and OT servers. Thus:

--- Bitmessage makes it possible for Nyms to perform currency wires from one OT server to another, through other Nyms.

--- Bitmessage makes it possible for Nyms to perform cross-server trades (by enabling discovery.)

--- Once discovery has taken place, Nyms can perform escrow, as well as market trading, since OT already supports those things.

For specific step-by-step walkthrus of the Bitmessage-related protocols, see the paste bins I posted at the top of this thread.



I suppose so, yes.


Yes, although at some point we are going to have it in the Monetas systray app. (For starters.)


The delay in/out of a legacy bank account will depend on the legacy banking API you are dealing with.

As far as I know, SEPA is near-instantaneous. ACH, not so much.


I can't really say, I haven't seen their code.


It's not the same as credit lines, no.

Not that credit lines are a bad idea -- I will eventually be adding them to OT as well.
(Especially now that cross-server discovery is solved…)


I believe that Bitmessage uses proof-of-work to prevent spamming.

Also consider that most messages can go directly through OT itself -- Bitmessage is only for discovery.

Also -- even if we swap out the discovery layer for something else, OT should continue to work just fine. (But so far I think Bitmessage is perfect.)


This is basically correct.

Bitmessage, however, would only be the network for discovery purposes. All other communications can go directly between OT servers, and P2P between OT wallets.


OT's cash instrument uses Chaumian blinding.

However, there are other instruments on OT which do not use Chaumian blinding: cheques, invoices, recurring payments, market trades, smart contracts, etc.

These other instruments, while not blinded, are still pseudonymous, and the receipts are destructible. (It can still prove everything without the receipt history, as long as you have the last signed receipt.)


It clicked for me.


Yes.


OT is a system for federated issuing and transacting of various currencies. It can work with and without blockchain-based currencies.

Bitmessage is a p2p system for messages as well as subscriptions/broadcasts.

In our proposed protocol, OT federated servers will utilize Bitmessage as a discovery layer to enable cross-server escrow, for the purposes of market trading and wiring of funds between OT servers (and in/out of the legacy banking system.)

You can read more details above.


Please see details above, especially the protocol details in the paste bins I posted.


OT is fully-functional and usable. At least, the server and command line, as well as the API and client-side scripts.

There is also a test-GUI, and Monetas will be coming out with real GUIs very soon.

But the real beauty is the things you can build with OT, by integrating it into your own projects.

We are working on the voting pools, and the p2p exchange stuff will take a bit longer since it was just designed last night.
(Although who knows, if the second round of funding goes well, we might have it out a lot sooner.)

I should mention, BTW, that OT is completely open-source, and any products released by Monetas will be open-source as well.


This isn't entirely correct. OT cash is untraceable. But if you want to prove you paid someone, then use an OT cheque instead. (And you'll have a cheque receipt…)


The exchange protocol wouldn't be over Bitmessage, it would be internal to OT.

Bitmessage would be used for the discovery process. See my paste bins.


I don't think banks will have to run OT servers.

Any colored-coin issuer can fully-obey KYC / AML.

The issuer would be entirely divorced from the OT transaction servers, which could operate on Tor.

------------------------------------------------------

I can also reveal that Adam Back believes he has solved the problem of homomorphic amounts (so the OT server can't see any of the amounts, on any of the transactions it processes.)

I will be integrating credlib into OT soon and also working with Adam on adding his homomorphic code to OT as well.

Ripple is centralized, closed source and it is not based on "the same underlying crypto" as bitcoin.
Everything on their site & wiki is lies.

Fellowtraveler, maybe we arrange something to test out your "voting pool" and BM-related ideas?

As for my comment you quoted, you know what is of greatest interest to Bitcoiners is how can it be used to create distributed exchanges.

Thinking about marketing and names I suggest to call it Nipple somewhat similar to GNU :)

Nipple - Nipple is not a [Ri]pple

EDIT: or more simple version

Not a [R]ipple

For those asking for hand-holding....


See the docs folder (https://github.com/FellowTraveler/Open-Transactions/tree/master/docs) for instructions on installing the pre-requisites.

Once you have those installed, this is usually what I do to build:


(The reason I configure with java is so I can run the test-GUI. (http://ft.vm.to/files/moneychanger/))

Then build the project:


You can also do "make -j2" or -j8 etc to make it build faster, depending on how many CPUs you have (and how much RAM.)

There is also now a tarball installable through apt-get (http://www.openwallet.org/downloads/) though I don't know if it's the most recent version (better to build it yourself, because then you can always "git pull && make install" to update to the latest version.)

Once you have it installed, I suggest you start by copying over the test data:


Then start up the server:


Then you should be able to use the command line tool (in a separate window):


Etc. You can also make scripts by putting "!/usr/bin/env ot" at the top of the script. (See the scripts/samples folder.)

If you want to try to OT test GUI (Moneychanger):


(You will probably have to tell it the /usr/local/lib folder, and then select an image from your harddrive.)

People ask why they have to select an image. The reason is so that hackers cannot do phishing attacks by tricking you with a fake passphrase dialog. They will have no way of anticipating which image you have selected to appear on that dialog, so it will look different for every user.

I should add that the test GUI is not representative of an actual OT GUI. It's just a visual representation of the API, for testing/developing purposes. To see what an actual GUI would look like, check out the screenshots of the upcoming Monetas iPhone app. (http://ft.vm.to/files/screenshots/)

You can get support on the OT IRC channel, #opentransactions at irc.freenode.net

Some people have contacted me asking about investing. I suggest you contact our CEO Johann Gevers: johann@monetas.net

Thanks a lot man, much appreciated!

As a non-native English speaker, my interpretation of 'federated' is somewhat ambiguous, would that be something like 'based on a universally agreed upon protocol' or something else?

And how do you mean 'discovery' in this context: finding eachother i.e. bringing people (or the services they request and provide) together?

Interesting, hadn't thought of that dimension ... but it indeed may take on a 'mind' of its own depending on the bots that will come to inhabit the various asset pair channels ... like an AI springing forth from the emergent behaviour of the collective of bots you mean?


Edit: ... and in this vein I propose the name for the OSS bundle comprised of Bitcoin Bitmessage Open-Transactions be the BITBOT bundle  ... and same name "BitBOT" for any AI that might spring forth  ;D

Herds next to watering holes(BMOT) as opposed to wild jungles(free-for-all exchanges *GOX). WoT is powerful and unknown, just look what Bitcoin did to financial tools in a short time - now imagine contract law, commodities, documents, voting...
We will build the trading bots to protect our wealth that can act in unison or pick and choose which bots best appeal to our current risk/reward. OT is the Wilderbeast Consortium and BM is the trumpet call.

Correct, the next step is to make it a distributed P2P application. And there will be some dynamic changing local agencies provide trading with enough volume

The benefit for this approach is: Like in a private auktion, if Alice do a bank transfer to Bob and buy some bitcoin from him, banks don't know the reason behind that transaction, the privacy is kept very well. If you do the transaction through an escrow, then banks will know clearly this money is going into a bitcoin exchange, at least that escrow holds all the information about all the transactions related to exchange

Vladimir, you can be accused of many things, but a failure of the imagination is never one of them.

I just wish someone would give this OT/BM idea as much air time as Ripple is getting.

This is not possible, if you take all of your money out of banks and store them locally, banks will all go bankrupt  ;D

Well actually due to Fractional Reserve banking all banks are "by their very definition" bankrupt. ;D

Like others I am very much looking forward to seeing where this leads.

 ..... This is the sound of Inevitability.  ;D

The escrow is performed by the smart contracts function on the OT server  ... https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/smartcontracts/escrow (https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/smartcontracts/escrow) how would the bank have any idea it was not just regular user making a transfer?

That OT server must be authorised by banks to access their SEPA transaction data, without that authorization it can only prove a bitcoin transaction, not a fiat money transaction

http://www.youtube.com/watch?v=x5m1A7zoIcc (http://www.youtube.com/watch?v=x5m1A7zoIcc)

Hear that Mr. Andersen ....

Are you sure about it?
Something tells me that the simple fact that a colored coin issuer can't control where his coins go to already makes it impossible for them to implement such restrictions on most jurisdictions.
Wasn't that the very reason ecash was dropped by banks?

But suppose it's legal. If I'm getting this right (and that's a big if, I confess I need to study this much more), in this new scenario MtGox-like institutions would emit colored-coins which could then be exchanged against normal bitcoins in a p2p, hard-to-track way. But to get fiat in and out, you'd have to go to your fiat-holder and then everything would be tracked as it is today. You'd still need to trust your fiat-holder not to commit fraud or disappear with your money, but, for sure, that'd be a harder coup to play than disappearing with your bitcoins.

So, we would no longer need to worry with "trade engine lags" and alike, and we would no longer need to store our BTC in a shared wallet. Any other big advantage?

Question: Wouldn't a p2p marketplace for escrows which do not hold your fiat be even better than that? The escrows only need to intervene when there's a dispute. But traders are still responsible for transferring funds to one-another, as in OTC. BTC-funds would be locked in 2-of-3 addresses, waiting for the fiat transfer to complete. No "bank-account to hold them all". If you have an API to access your bank account (think merchants) you can even automate everything, as the look-up for escrows could be based on deterministic criteria.

You changed from "banks will know clearly this money is going into a bitcoin exchange" to "OT server must be authorised by banks to access their SEPA transaction data" ... which are obviously two different issues. Interfaces with legacy banking system are problematic but they can't stop individuals making transfers or their money would become more useless than it already is ... the more barriers they put up to personal transfers the less valuable their money becomes ...

The only problem is this doesn't sound very user friendly. How can it all be turned into a simple web app?

Wow... this is big!!

Very interesting! Great work you're doing. I've got to read up on all this; I think this work might benefit something I've been working on myself :)

Bitmessage sounds a bit unscalable, the white paper says you are attempting to decrypt every single message that comes in over the wire with all of your local keys... That would quickly get wasteful and cpu intensive

Read the paper, it's addressed.

A colored coin issuer can demand KYC info from anyone converting in/out directly through that issuer.

Therefore the issuer is compliant. (Consult an attorney -- that's my opinion, and it's not legal advice.)

This is no different than MtGox is today: users are giving each other BTC all the time outside of MtGox -- but only the ones who cash out through a MtGox bank wire actually have to cough up their identification info.

Similarly, people could be giving each other colored coins all the time -- but only the ones who actually cash out through the colored coin issuer will actually have to cough up their identification info. (The coins that circulate outside their reach are comparable to dollars which circulate outside the reach of the Fed.)

... So for example, users could utilize local meetups...

...Or as I have proposed, users could use OT escrow in combination with SEPA to directly redeem...

Open-Transactions is always going to be about a wallet-centric solution, not a provider-centric solution. We want provider independence.


As long as the issuer performs redemptions "of last resort" then technically, you could move fiat in/out through any other user.


This is similar to what I have proposed. Stick the BTC in a multi-sig voting pool for safety, and then use Open-Transactions escrow and Open-Transactions markets for the actual exchanges.

(Except in my proposal, everything is automated.)

From there, Bitmessage provides discovery layer. But there's no reason why OT itself couldn't have its own broadcast net, nor why we couldn't use something like IRC to serve that same purpose.


Well in my proposal, I wrote: The above protocols can be implemented inside OT wallet GUIs, such that they are automated and transparent to users.

Why does that not sound very user-friendly?

People have often complained that OT was "too complicated" -- but I guarantee you they are wrong. (These complaints predate the high-level API.)

For example, see the high-level API (https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases) -- most financial actions can be done in a single line of code. Developers couldn't ask for easier.

And see the screenshots for the upcoming iPhone app (http://ft.vm.to/files/screenshots/) -- Users couldn't ask for easier.

I was trying to be nice by giving everyone a few years head start on creating their own OT clients... That doesn't mean easy clients aren't possible, because I personally haven't released one yet. It just means I wanted to allow others the chance to release them first. (So I could focus on the core library...)


I should point out that most of the solution was latent inside Open-Transactions itself. I'm actually surprised no one else thought of it before -- I mentioned the idea on my FAQ years ago.

Bitmessage is very useful as the discovery layer -- but there's no reason why you couldn't swap in a different discovery layer.

For example, the same solution is basically just as easy to do by using IRC as the discovery layer.


I can't speak for Ripple (I haven't seen their code) but OT doesn't contain central points of failure.

Open-Transactions is user-centric, not provider-centric.

Excellent reading, fellowtraveler! The flaw that springs to mind is with SEPA (ACH may be similar).

Problem: The SEPA protocol allows for refunds, so allowing both Alice and Jorg to profit through subverting the OT process.

As at [1]: "Payment service providers originating an SCT can request a recall of duplicate or erroneous transactions."

An SCT is a "SEPA Credit Transfer", the kind of transfer I think we're thinking of when we think of using OT to transact. As at [2]: "A recall can be requested by originator bank on behalf of its customer to cancel a SEPA Credit Transfer already settled at EBA. This must be initiated within 10 banking business days after execution date of the SEPA Credit Transfer subject to the recall. Before initiating the originator bank has to check if the SCT is subject to duplicate sending, technical problems resulting in erroneous SCT or fraudulent originated Credit Transfer."

(An SCT is distinct from an SDD - "SEPA Direct Debit" - which allows much longer recalls, as at [3]: "For unauthorised transactions, this right to a refund extends to 13 months after the due date.")

Abuses:
[1] Jorg abuses both Alice and Bob. While we might assume that we can detect that Jorg paid Bob via a SEPA call, Jorg could wait until receiving his payment and then contest that payment was made fraudulently thus retrieving the value deposited to Bob. Alice would then be faced with having to re-pay a settled bill.
[2] Jorg and Alice collude to abuse Bob. Alice wants to buy two silver coins from Bob. Alice pays Jorg, Jorg pays Bob, a SEPA call shows Bob as paid. Bob ships the two coins and provides Alice a shipping number. Alice, knowing the coins are now irretrievable to Bob, informs Jorg who disputes the SEPA transfer, receiving back the whole value sent. Alice also disputes the SEPA payment arrived and so the escrow mechanism divides her payment to Jorg in two, and returns her half. (Although note: Jorg could agree to return an arbitrary amount even subsequent to escrow completion.) Alice now has two silver coins at half price, Jorg has profited by pocketing the other half of that price as well as his transaction fee, and Bob is down by the whole price.

Solutions:
1. If a SEPA call and the protocol also allows for the status of an old transfer to be detected (not clear from my research), this would allow an automatic input into both the reputation system about Jorg (and potentially automated contact to Alice and Bob, if they could elect for such);
2. This puts greater urgency on the reputation system, and also a first approximation of the reputation increase cycle - that is, 'noob' for at least ten days following the first transfer;
3. A system by which payments are made through a client-initiated federation of actors: Bob requires Alice to pay via 3 intermediaries. Alice's client randomly chooses and pays Jorg and Carol and Ted all of whom then pay Bob. This reduces Bob's risk of total loss and increases Alice's risk of being caught by a good actor;
4. Extending (3) above, support for confederations of actors. Alice & Bob may request that only a guild matching certain parameters handle payments, where a guild is decided on (say) a volume basis ("traded $1m+ in last 30+10 days, >99.5% uncontested transactions in those 30"). The guild would be in charge of their own arrangements for membership and distribution of work/reward. A single trader with a large volume would also count as a guild, but is unlikely to have the highest rating but either way a guild is unlikely to risk that whole business abusing Alice and Bob's trivial sum. A guild might well (for instance) choose to incorporate in one or more jurisdictions and use this as a selling point, even though it may well mean higher transaction fees in return. As part of that business, they may well elect to insure Bob against Alice colluding with one of their members.

Cheers!

[1] http://www.paymentscouncil.org.uk/files/payments_council/sepa/shortcut_to_sepa_credit_transfer_%28sct%29%5B1%5D.pdf
[2] http://www.rbs.nl/docs/MIB/Country.../SEPA_FAQs_RBS_NL_v2_2012.xls
[3] http://www.ukpayments.org.uk/files/payments_council/sepa/epc222-08_version_2.0_shortcut_sepa_direct_debit.pdf

Miner_Willy, this is an excellent point. However, there's no reason why the users can't just cash out colored coins with each other WITHOUT using SEPA. Which they can do, as long as they trust the colored coin issuer to perform redemption "of last resort."

And then the actual "last resort" redemptions (through the issuer himself) can all be legitimate (non-reversible) and can occur through bank wires and AML/KYC.

Therefore I believe this solution still stands, even without SEPA.

P.S. I agree with you about the usefulness of a reputations system. How about Monkeysphere? (I will have to defer to the experts on this...)

Excellent work, folks. I have donated and I hope everyone else here will too, when they realize the immense potential of this unique combination of protocols.

This is innovation at its finest!


 :-\

Well, not like I'm not already halfway down the rabbit hole, I guess I don't mind if it gets a little deeper ;D

Where can i donate for this project?

Is this correct address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ ???

Yes.

This is really great news. Hope to see it moving forward. I'll be sending a smallish donation later. Keep up the good work guys!

0.53201 sent.

Thank you for this - I don't see anything more important happening anywhere in bitcoinland.

Thanks for developing this tool. Truly amazing. 3btc sent!

More step-by-step...

1. Wallet uploads BTC to voting pool, in order to trade them around on an OT server.
    -- AND/OR --
1. Wallet uploads colored coins to voting pool, in order to trade them around on an OT server.

Also notice that the colored coin issuer does not directly issue anything onto an OT server. Issuers can issue directly onto OT servers, but I suggest using colored coins and voting pools in order to break that link.

2. From this point, it's easy to use Open-Transactions for escrow, and for market trading, on that OT server.
   (Server is unable to forge receipts internally, nor steal from multi-sig pools externally.)

3. Using a discovery layer (Bitmessage, IRC, etc) users who are not already on the same OT server can discover each other, and select a server to meet on, to complete the trade / escrow. (This can all be automated inside the client software.)

4. The same discovery layer makes it easy to wire funds from one server to another, through other users.

5. The same discovery layer makes it easy for users to discover each other for SEPA transfers, facilitated by OT's escrow capabilities.

6. These SEPA transfers could also be performed by services, who are themselves just "other users." (This is the basic concept of Ripple "gateways" as far as I can tell.) OT escrow is used here to remove trust.

7. Even credit lines could be issued cross-server, now that the discovery layer is solved.

The specifics of the discovery/OT protocol are in the paste bins at the top of this thread.

All conversions for a particular user are performed by his own wallet, in a user-centric fashion.

We need to move away from a provider-centric mindset, and instead become provider-independent -- demoting servers from "authorities" to mere "cloud commodities." (For examples of this concept, see Diaspoa and Tahoe.)

Admired and appreciated. Please continue. 2btc sent.

Thank you fellowtraveler and all who are working on this!

Keep up the good work, this sounds brilliant :)

Love this idea, writing about it right now for a blog post on p2pconnects.us

Have you heard of / considered Tent.io? https://tent.io/

BitMessage seems great as is, but it's just something else to consider if BitMessage ends up having limitations that Tent.io doesn't.

Very excited about this. Watching with great interest.

Watching this as well.

Damn; throw this all into a "killer app" GUI (I know, that's the last thing on the dev's 'to-do' list, and rightfully so) and this could be earth-shattering. I'll be following this thread (and bitpools; man, people seem to be just churning out killer apps these days. Good for bitcoins, good for the world!)

It would be really cool if some more people could ACK this proposal in Meta:

'Open Transactions' subforum in Project Development (https://bitcointalk.org/index.php?topic=189019)

Bye bye Ripple.

You're getting slow in your old age...  :P

https://bitcointalk.org/index.php?topic=212202.msg2229999#msg2229999

Heheh, this shows you do recognise the value of Ripple, and are only worried about XRP displacing Bitcoin and miffed that Ripple doesn't have mining, totally contrary to your own assertions. Ripple, OT, Bitmessage, Zerocoin, and all kinds of other P2P tools are largely synergetic and partially competitive, and both of these are a good thing.

You're probably right. But IANAL either.


Fantastic.

I really need to read more about it. Since my first introduction to OT I was impressed by it. It seems its time is finally coming. :)

As soon as have my hands on my wallet, you'll receive a small contribution of my part for your great work.
Thanks!

First it's Bitcoin early adopters are no different from Opencoin Inc's printing press, then it's OT is no different from Ripple, there seems to be no bottom to the Ripple pimps' absymal intellectual capability, and that's why you should stay away from them.

Heheh, I was advocating OT and Bitmessage as an alternative to Ripple before you guys started talking about it. Ripple enthusiasts aren't Bitcoin haters or OT haters. The only ones who do the hating are a small but vocal band of intellectually dishonest people who are afraid to lose their money. Bitcoin, Ripple, OT, Zerocoin, Bitmessage, Tor, I2P etc etc are all great and largely synergetic. We live in very interesting times, let's not let a small group of haters spoil it.

smart people working like this beats academia by a mile

fellowtraveler went from idea, peer review, to increased funding (literally cash in hand) and collaboration in less than 24 hrs. 

LOL, that made my day :D

But seriously, really excited about this. Let's put some serious work on this thing.

Fellowtraveler has been determined to see OT succeed since introducing it many moons ago. I have pointed out the need for OT, as have others, to key developers on the forums/IRC which fell on deaf ears.
Only the latest fears of de"gox"ification has opened everyone up to the possibility that we had the solution in front of us all the time. This is not a download once, free mined coins, windows-only easy pie GUI. This solution requires work by server dudes, graphics guys/gals and architecture.
BMOT is a framework that opens a new playground. SCAMMERS WON'T LIKE THIS PLACE and traders must play fair. No more speculation walls or bit* scams allowed. Bitcoin and altcoins acting cooperatively and contracts/commodities/PMs from legitimate sources or GTFO! This has a built in stop button! No more jungle tactics. The strong will survive and thrive, but the newbies can cling to the strong instead of being fleeced by the wolves.
TLDR;
FT has waited for the perfect moment to reintroduce Open-Transactions.
OT with BM can setup groupings of pooled interests.

wow so the DOJ cracking down on gox's US account might be the best thing to have possibly happened for OT and p2p exchanges generally

Well, I thought OT would have it's great moment when GLBSE 2.0 went down, seems no exchange website picked it up though.

Maybe this time with exchanges mostly not really threatened by their incompetence (= being hacked) any more but rather their environment (= regulatory issues and accounts seized) OT will have it's moment...

Realisitically though to be honest, there is no need so far to wait for BM integration, OpenTransactions could already work for months on exchanges - all BM would enable is a decentralized network/order book between the exchanges as far as I get it. If people really think OT is the next level of IOU trading, they could have done so via different channels already for months/years.

PoW in BM instead of PoS and destroying XRP in Opencoin Ripple as spam prevention tool is a proven concept in Bitcoin, but it is also proven to be quite difficult in practice. Let's see how long it takes until I can withdraw BTC (and USD!) to OT on one of the top 5 exchanges on bitcoinmarkets.com and deposit them elsewhere...

Hello everyone

fellowtraveler,
It appears to me that you need an API command (https://bitmessage.org/wiki/API_Reference) 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?

Bitcoin credit unions are already being built. Build one in every city.
http://www.reddit.com/r/Bitcoin/comments/1eu87f/

Sorry to keep asking, but I still miss one crucial point.

For all this to work, if Alice wants to buy bitcoins with dollars, at some point she'll have to put some money into the OT+BM ecosystem by means of a wire transfer (I mean a classic oldschool bank transfer or SEPA transaction). How can she be sure the person she wires her fiat money to (let's call him Bob) doesn't disappear, or claims he never received it, or otherwise screws her over?

From what I've read, Bob has to put in some crypto currency as collateral, so that if he disappears with the money, he'll actually end up losing more than he took from Alice. Is this right? If yes, how can Bob be sure that whoever he pays collateral to, won't disappear with that?

OR, what happens if Alice claims she wired her dollars to Bob's bank account, but she actually never did. Who's going to decide if Alice or Bob is right?

I've been following this thread, felt like jumping in here.

I think the idea is escrow, rather than collateral. Both Alice's SEPA transferred funds and Bob's crypto would be floating in the air at the same time if I'm understanding things properly.

Uhm, how can the OT+BM (or any non-banking) system put any constraints, control, or monitoring on wire transfers which occur only between banks? I mean Alice can say her SEPA funds are in the air, but who knows if they really are?

I'm not sure how this escrow thing works. Is that based on trust (and how is that assigned?) or some smart novelty that eliminates the need of trust?

I believe that OT server doesn't hold funds directly, but waits until transactions are ready to be forwarded and then signs them off. Doesn't the anonymity gained from OT come from two parties not directly sending funds to eachother?

I'm just going off of what has been posted in the thread so far, I'd love to hear someone more knowledgeable to give us a summary on example transactions.

Imagine: Federated OT servers act like agents who agree on outcome with "best data" versus "best guess".
My friends and I set up a consortium of bitcoin/litecoin/bytecoin/etc and an offer sheet with floating values that our bots are deciding versus other consortiums or solo players. Money exchanges are still guarded by local laws, so we all need to check with lawyers or regulators.
Imagine: My bitcoins are colored to reflect straight up trades and not speculative trading. Litecoins are being used in arbitrage to balance trading gaps between sudden moves on markets that cannot enter money exchanges.

No problem. Excellent questions!


…and get money back out again. I assume by this you mean "legacy cash money in hand" and/or "legacy money in the legacy bank."

--- Keep in mind that most transfers will happen inside the OT system, or on the blockchain…
--- That is, while bailing legacy cash in/out of the system is possible, that should not happen for each and every transaction….
--- Also keep in mind that once you bailout BTC or colored coins from an OT server, then it has passed outside the sphere of OT, and you can cash it out in whatever conventional way that you normally would, based on the existing market for Bitcoin services. (This would be an option as well.)
--- …Therefore I restricted my Bitmessage examples to only cases where the two parties both are transacting within OT. (The reason being that we can then assume that OT's powers apply -- such as markets and escrow.)

That having been said, here are various options I can imagine for bailing legacy funds into/out of the system …

=> Bitcoin ATMs. These were at the Bitcoin 2013 Conference in various configurations, and so the option is rapidly approaching to use them.

=> Through your social network: This was always what enamored me of the Ripple idea originally -- that instead of using a centralized exchange, you can just "go through your friends." And if your friend will hand you some cash in return for a Ripple transfer, then similarly he should be willing to hand you some cash in return for an OT or blockchain transfer. (And vice-versa.)

=> Geolocation: Apple has recently publicized the concept of people providing ATM service for each other. Your iPhone just finds someone nearby who hands you $60. (At the same time, $62.50 is charged to your iTunes account.)
The same could clearly work for colored coins in a P2P app. (Even the open-source community could easily build such an app using OT -- though Monetas itself possibly could not, depending on the status of Apple's patent.)

=> SEPA transfer: In Europe, bank users can quickly and easily send transfers to each other's accounts through the SEPA API, and verify whether such transfers have been made.

=> Meetups: There are already local Bitcoin meet-ups; thus it seems like a viable method of exchange for cash.

=> Gateways: (Ripple seems to have popularized this nomenclature, so I'm going to use it here.) This is any business that users are willing to trust for the purposes of sending/receiving bank wires, SEPA transfers, ACH transfers, etc.

===> The main difference here is that in the case of Open-Transactions, your funds would not be stored as an IOU from the gateway. Many have said that on this forum, but that is not actually the case. On OT, you are buying/selling BTC and colored coins, instead of issuing IOUs.
(Issuers do have the ability on OT to issue IOUs, but that is not the solution I've suggested in this thread. Rather, I've suggested to store the actual coins in voting pools so that an OT server can transact them without having to be trusted not to steal them.)

===> In the case of OT, the "gateway" becomes a "trader". Instead of holding IOUs from a gateway, you are purchasing or selling BTC or colored coins from a trader. And that Trader is NOT an OT server -- but another OT user, like you!
And since this transaction is occurring inside an OT server:
- it will be instant, instead of requiring blockchain confirmations.
- It can be performed on a market, where orders are automatically matched according to their criteria.
- It can be performed through the use of escrow -- and the terms of that escrow can be customized by the parties (since the escrow itself is implemented as a smart contract -- and users can customize their own smart contracts.)
- Via Bitmessage, wallets can coordinate cross-server wiring of funds, as well as cross-server order matching, and cross-server discovery of other wallets willing to make transfers in/out of the legacy banking system, by way of OT escrow.

===> In any case, whether you are obtaining IOUs from a gateway (Ripple), or whether you are buying/selling BTC and colored coins from a trader (OT), either way, I assume that such businesses will be willing to take/pay cash at their physical locations, and bank wires otherwise. (Otherwise, why are they even in this business?) Therefore, you can move legacy funds in/out through such businesses.
Personally, I prefer cash-in-hand over IOUs, which is why OT places such a high value on the ability to customize your escrow terms.

=> Bank Wires: One example of why I prefer cash-in-hand: If you purchase precious metals for physical delivery, you will discover that orders can be shipped based on a bank wire, yet the same business is not willing to ship based on a credit card purchase (due to chargeback risk.)
Therefore bank wires are a valid method for getting money in/out of the bank account, albeit slow and expensive.

=> Bitcoin Exchanges: exchanges are one way to trade Bitcoins for national currency and get a bank wire, so it deserves to be on this list. Any BTC traded on an OT server could presumably be bailed-off of OT and cashed-in through a Bitcoin exchange (with the laws in that jurisdiction applying.)

=> The original issuer: In the case of colored coins, there is some issuer in some jurisdiction who originally created--and has agreed to redeem--those colored coins. Presumably he could be paid (and pay others) through BTC or through bank wires or cheques.
NOTE: Most actual users shouldn't have to deal with this guy directly. Another note: Once users have uploaded these coins into multi-sig voting pools, they can then devise basket currencies to hold and transact with. This enables users to distribute the risk of a single currency across many issuers.

=> Prepaid card / bank card: It seems that a prepaid card could be given to the user, with funds placed onto the card easily enough based on whether the user had paid the card issuer on OT.
- Escrow probably not necessary in this case, and card issuers can demand to be pre-paid.




She cannot, although the above examples are all different. This is why I place such a high premium on escrow, reputation, risk limits, and cash streaming protocols.


If the money is stashed inside a smart contract on OT, then the OT server is incapable of forging any receipts internally, nor is it capable of stealing BTC or colored coins from the multi-sig voting pool those coins should be stored in. Therefore the holder (OT server) cannot disappear with those coins.

You might ask, but which party to that smart contract is ultimately going to get the funds, in the event of a dispute?


This is totally determined by the smart contract itself. And since these can be customized (through scripted clauses), then ultimately the open source community will have to decide for themselves, for the various cases, what is an acceptable distribution of risk.

For example, let's say that Jorg is receiving colored coins all day, in return for SEPA transfers. He might deal with scammers all the time, which is why he demands a smart contract where the funds go into escrow and he can verify their existence (safely stashed there) before initiating the SEPA transfer.

Also, let's say that his terms specify that once he notifies the smart contract of the initiation of the SEPA transfer, he is guaranteed that he will receive the escrowed colored coins after X hours, unless Alice files a dispute.

…And in THAT case, say the smart contract terms require the decision to then be rendered by Judge Judy (as the sample escrow contract in OT actually does.) And then things will either be proved to her, or they won't. (And if you don't trust Judge Judy's adjudication skills, then don't use a trader who insists on using Judy's contract.)

Jorg might have to operate based on a whitelist or even a blacklist -- but at $X per transfer, he'll be operating. And remember, he's not issuing IOUs -- he's just buying and selling BTC and colored coins. He's also not operating an OT server, since he is actually just another user, like you.



Here is an article on Open-Transactions smart contracts. (https://github.com/FellowTraveler/Open-Transactions/wiki/Smart-contracts)

--- To whatever degree that SEPA API calls are possible to automate verification of transfers, then I'm sure those will end up being used.

--- To whatever degree transfer protocols are possible based on parties providing manual notifications to the smart contract of certain payment events, those will be happening as well.

--- To whatever degree that "Judge Judy" has to get involved and make a human decision, in the case of disputes, then smart contracts will have to support that mechanism. (The escrow sample contract that comes with OT, already does this.)

---- To whatever degree that whitelists, blacklists, and other reputations systems become necessary, (monkeysphere ?)

--- …as well as to whatever degree risk limits and cash streaming protocols will be used, they will be, -- wherever they enable new transactions that people could not previously perform.

http://davidsasaki.name/wp-content/uploads/2013/02/Centralised-decentralised-distributed.png

      Central Banking                           Open Transaction Confederation                          Bitcoin



OT is able to confer properties of a decentralised network ... and Bitcoin is actually a highly "distributed" network (any node to any node), a special case of decentralisation.

I should also mention:

1. Cross-server transfers of funds will involve smart contracts verified by the servers on both sides. (Not by the users.) This is only for OT-server to OT-server, but still worth mentioning. The server itself would have to be "in on" the scheme with Jorg -- and an OT server can't forge receipts.

2. Conversion of one currency into another (on markets) is also performed by the server, and thus you don't have to trust the user you're dealing with. The same goes for escrow, for all internal transactions. Bitmessage allows you to find these other users, but the actual transactions are then performed on OT.

Now I'm wondering if OpenCoin will try to buy out Monetas.

This is a very different definition of distributed/decenteralized than is used in some other places.

The other one is:

Visa's network is distributed— there are servers in many datacenters that share the work. But they are all controlled by a central party, they are not decentralized. Likewise, google, any CDN, basically any highly scalable modern service is distributed.

Decenteralized means there no central authority at all. Very few systems are decenteralized, though arguably many system-of-system federations are at least to a degree decentralized.

Right. What does bitmessage accomplish for you that a tor hidden service wouldn't accomplish? Or an IRC channel?

I thought OT federations needed unjammable broadcast networks in order to prove that they weren't performing inflationary double issuances of the assets they published notes for?

As far as I'm aware there are no precise mathematical/engineering definitions for centralized and decentralized networks? Obviously any network without a central hub controller is decentralized, can we agree on that at least?

I dont' know how other people use it but I thought the posted diagrams make clear the differences. I have seen node-to-node type networks (rightmost picture) referred to as distributed for a long time (3 decades already maybe?) but also they recently call them "mesh" networks. To add to the confusion, in many real-time networks applications SCADA (supervisory computer and distributed acquisition) were some of the first decentralised systems on the market, alongside their competitors/counterparts the DCS (distributed control systems) which actually were much more 'centralised'.

Perhaps it is time for someone to sort all this out with a good paper tabulating the network topologies nomenclature, fractal measures, scaling properties, etc? You might be up for that?

The OT servers are definitely not all controlled by a central anything. Each has its own server operator, presumably.

Also, an OT server is not an authority over anything, but would be more accurately termed a "cloud commodity."

The authority should be the user wallet itself, not any provider/server. Similar to Tahoe-LAFS: provider-independent.


I have repeatedly said in this thread that most of the new capability here is latent in Open-Transactions itself, and that Bitmessage only solves discovery.

I have also explicitly said that IRC could most likely be swapped in to replace Bitmessage -- and it would probably still work. (I don't see why not.)

In fact the OT servers themselves could even allow users to post and share certain announcements in order to solve this problem.

A Tor hidden service, as you suggest, would probably also work -- though it seems to be the most centralized form of all the suggestions.

I will definitely be coding it to use an abstraction layer so that different options are possible.


The purpose of the broadcast as discussed in this thread is purely for discovery purposes, not for auditing. Each OT server does need to make certain audit information available for query (it doesn't have to be stored in any censorship-proof medium.) But that's not the same thing as the discovery process that makes possible these cross-server wires, cross-server trades, and server/legacy bank transfers.

Thanks for all the info FellowTraveler... I have one question though, what are "multi-sig voting pools", and how do they work? Do they actually hold onto funds, or do they just sign off on transactions involving them?

Just want to say that when I see BMOT, I'm my mind I read it almost like бeгeмoт (begemot, e as in west), which is Russian for hippopotamus or behemoth. That second one sounds strangely foretelling  ;)

For people that just want to buy and sell BTC once in a while - as opposite to those who wish to profit from active trading -, what's the advantage in holding fiat-backed colored coins?
Couldn't the same scheme of escrows and everything be used to acquire BTC directly, instead of going through colored coins?

By the way, I think using alternate chains with merged mining is better than using colored coins in the main chain. Colored coins would likely be "tagged satoshis" if I'm not mistaken. To transfer these colored coins around, you'd need actual bitcoins to pay mining fees (and first of all, you'd need a pool that's willing to ignore recent standards on anti-dust). That means that to move your "dollars IOUs" around you'd need bitcoins to pay the transfers fees. It's kind of weird, and will make this system only useful for those willing to acquire bitcoins - and these ones, AFAICT, will not have any other reason to hold these colored coins than active trading.
If instead you use an alternate chain where only fiat-backed coins exist, the mining fees would have to be payed in fiat-backed coins. That's more reasonable, and may even become a strong competitor to legacy fiat transfer methods, without requiring the user to hold bitcoins not even for a second. That could grow more quickly, and extend the advantages of "Bitcoin the payment network" to those who refuse to hold "Bitcoin the currency".
As an extra, as this alternate chain would have no currency creation, we'd already have an experimentation case for fee-only mining subsidy.

A single alternate chain could be created for holding everything related to the "issuance of tokens". It could hold everything you'd be willing to use colored coins for, I suppose.

Consider the various forms...

----------------------------------------------------------------

GOLD ISSUER

1. The gold issuer issues gold units onto the OT server.
2. Any user who has the currency contract is able to open accounts denominated in those units, and from there, withdraw cash, write cheques, trade on markets, etc.

===> In this example, the OT server cannot forge any receipts. The only possible crime is inflation, but the gold issuer has an incentive to audit the OT server, which prevents inflation.

----------------------------------------------------------------

EURO COLORED COIN ISSUER

1. The Euro issuer issues colored coins.
2. Users have the option to upload these colored coins to OT servers (preferably via voting pools).
2. Any user who has done this is able to open accounts denominated in those units, and from there, withdraw cash, write cheques, trade on markets, etc.

===> In this example, the OT server cannot forge any receipts. The only possible crime is inflation, but the other voting pool members have an incentive to audit the OT server, which prevents inflation.

----------------------------------------------------------------

BITCOIN WITHOUT MULTI-SIG  (not recommended!)

1. The user uploads the BTC or colored coins to the OT server.
2. The OT server then issues the appropriate units to the user.
3. Whenever the user wants to get his BTC or colored coins back out, he sends a signed request to the OT server along with the units, and the server sends his BTC back to him on the blockchain.

===> In this example, the server would have to be trusted not to disappear and steal all the BTC he's holding.

===> The server would also not have any incentivized entity performing audits to prevent inflation.

===> The one benefit is that the OT server cannot forge any of your receipts (so at least the amount he owes you is provable.)

===> This configuration sucks (I do not recommend it) but this is basically what the entire Bitcoin world has been doing, up until this point.

===> This is why people keep getting screwed in the Bitcoin world. The server just disappears with your money, or gets "hacked."

----------------------------------------------------------------

BITCOIN **WITH** MULTI-SIG

1. The user uploads the BTC or colored coins to a list of BTC addresses, instead of to a single address. Each one of the addresses on this list belongs to a member of the voting pool.
2. Each voting pool member is an OT server. Once BTC or colored coins are in the pool, then only an M-out-of-N vote from the servers -- on the blockchain itself -- can retrieve those coins.
3. If the user wants to get his BTC or colored coins back off of the OT server, he sends a bail-out request, which the server countersigns, and then they forward this to the pool members, who verify the signatures and vote ON THE BLOCKCHAIN to release the coins back to the user.
4. Even if the OT server disappears entirely, the user can still submit a recovery request to the other pool members and get their vote, and get the coins recovered.
5. In answer to your question, the coins just sit in the voting pool the whole time while they are being transacted on the OT server. Ideally they will change hands a hundred times, a thousand times, a million times, before being pulled back out of the pool. The whole point is to enable off-chain transactions on transaction servers, with escrow and markets, etc, and to avoid expensive and traceable blockchain transactions except where necessary.

===> The only crime left to the OT server (who cannot forge receipts) is the crime of inflation. However, the other pool members have an incentive to audit each other, which prevents this crime. Therefore the pool itself replaces the "gold issuer" in the original example. See the Open-Transactions auditing doc. (https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing)

===> You do not have the trust the individual servers, but you DO have to trust the POOL ITSELF. If a hacker were to gain malicious control over a majority, or 8 out of 10, or whatever, of those servers, then he could steal the funds in the pool.

===> This is why I would go even further, and use a wallet GUI that distributes my funds across multiple pools, and/or uses basket currencies to distribute a single currency across multiple issuers / multiple pools.

Ultimately, you cannot eliminate risk entirely, but you can reduce it, and distribute it, and take advantage of separation of powers.

The concept with OT is to create a wallet-centric experience for automating this, to achieve provider-independence. (Like Tahoe-LAFS.)



Yes, an issuer can directly issue his IOU units onto an OT server, without having to go through colored coins.

But colored coins are important IMO because they allow you to sever this direct link between issuer and transaction server.

That is, you can still have issuers, and you can still have transaction servers, but they are no longer directly connected.

This is important for liability reasons, and it eliminates the issuer's ability to pick and choose transaction servers (meaning that authorities also cannot pressure the issuer to do so) and it also allows the users to buy and sell the colored coins as commodities, similar to BTC itself. Trust me, if you work through the exact differences between those scenarios, you will see why it's better to issue them as colored coins. (But OT will work either way, yes.)

Colored coins are specifically for Dollar or Euro based currencies, or even gold-based currencies. For BTC, on the other hand, you just use BTC instead of colored coins. Then you have no issuer and the BTC itself is the primary currency being exchanged. OT will work either way.

I can understand the advantages of colored coins over OT-IOUs (well, I guess I can, it's mostly the strong censorship-resistance of cryptocurrencies, right?)

But the use of colored-coins as a method of fiat transferring (i.e., as a direct competitor to PayPalUSD or Dwolla or whatever) would be strongly hindered IMHO if one has to pay bitcoin fees in order to transfer these "fiat coins".
I still think a dedicated chain for holding these tokens would be better than coloring coins in the main chain. Don't you agree?

Right. More specific reasons already detailed above.


I think it's open for debate, and the market will decide, but personally I disagree.

Why?

Because in my concept, you are only very rarely moving the colored coins in-and-out of the pool. Rather, you are trading them INSIDE OT. So your Nym, INSIDE OT, gives some colored coins to another Nym, INSIDE OT, perhaps by way of market trade or escrow agreement, in return for some other BTC or colored coin INSIDE OT, or in return for some legacy funds in real-world cash or in a real-world bank account.

As I've said, I would not want to move coins in/out of the pool for every transaction. Instead, I would keep them in the pool (in OT) for thousands of transactions, only moving them in/out when absolutely necessary.

...And the reason I would store BTC and colored coins on the main chain, instead of some alternate chain, is because I believe the security is best there. Since they will be "just sitting there" for some time, I prefer they sit somewhere safe.

But don't you lose the censorship-resistance features of cryptocurrencies once you deposit them on a particular OT-server? Can't the server be killed, freezing all accounts within it?

You are also probably not considering the advantages of holding provably backed bitcoin OT tokens versus bitcoins themselves ... vouchers, checks, near instant off-chain TX, untraceable blinded cash, recurring payments, plus other stuff. There are payment advantages (i.e. additional monetary properties) to having OT tokens. Think of OT as a decentralised system layered on top of the bitcoin mesh ... and you start to see the bigger picture.

I think if you read the above posts I wrote, you will see that no, you don't lose the censorship-resistance features of the cryptocurrencies, because they are not sent directly to the OT server, but rather, are stored in a voting pool on the blockchain, where those coins are recoverable even in the event that the server itself disappears.

Also -- what is your "account" ?

On OT, your "account" is just your last signed receipt, and you and the OT server both have a copy of it. In fact that's all you really need to keep a copy of -- all the older receipts can be discarded and the system can still prove everything.

If the issuer creates IOUs, and the OT server disappears or "freezes," then the issuer can just re-issue the same units onto a different OT server and it can earn the transaction fees instead. (The problem with this is, what if jurisdictional authorities, or criminals, use violence to force the issuer to abandon a specific transaction server? This is why I recommend adding the cryptocurrency layer...)

If you add the cryptocurrency layer, the issuer will create colored coins and release them (Or the miners create BTC and release them.) Either way, when a user uploads those coins into the multi-sig voting pool, they are safe in the pool (the transaction server can't steal them, and the issuer has no power to pick-and-choose which transaction servers are being used -- the users choose.) If your transaction server disappears or "freezes," then your wallet can just submit a recovery request to the other pool members and get their vote on the blockchain, and get the coins back.

What if the entire POOL gets hacked? Then you are in a bad position. Ultimately the only solution is to have a well-designed wallet which distributes risk across multiple currencies and multiple pools. This is where I think everything is going, and that's what I am building.

My apologies for making you repeat yourself. I ignore how these voting pools work. I'm guessing it's a large multi-signature thing (many people together can replace the signature of the server), but definitely I need to study it a lot more.

Thanks.

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.

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.

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

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.

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

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

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

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?

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.

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.

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.

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

really excited about this. :) great work fellowtraveler

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

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

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

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

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.

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.

Done (https://bitmessage.org/wiki/API_Reference)

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.




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


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. (https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing)


This sounds like a question better posed to the author of Bitmessage (Atheros.) My own project is for transaction processing, not messaging.

<off-topic>


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. (http://www.timesofhacker.com/2013/05/liberty-reserve-owner-arthur-budovsky-arrested.html)

Have you tried libertyreserve.com lately?

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

Very exciting stuff!

Thanks! (Corrected in original post.)

I never tried it.
Wasn't aware of it. Thanks for the link.

beautiful

bookmarked.

This.

And further,point 11 in the pastebin on silver/euro SEPA:

This is not a fair resolution method, is it? If the escrow has no way of knowing, then Alice is always incentivised to dispute.

Unless the bank wire is publically verifiable as well as irreversible, the fiat part of these exchange models always seems to be broken.

I believe dansmith has the essential elements of the solution in the discussion we've been having here:
https://bitcointalk.org/index.php?topic=173220.0

I'll give you the precis as that's a lot of reading. In case of dispute, the BUYER of fiat (not the seller) can be requested to run an open source plugin that reroutes their banking SSL session through a proxy (after they've logged in), the proxy can be the escrow agent or another user of the P2P software, the encrypted data is dumped and using the master key for the session, the data can be read such that it's verified that the fiat buyer did/did not receive the fiat funds (the fiat buyer only needs to show their bank statement for the period). Thus it can be made public knowledge whether the fiat was transferred or not.

Agree fully with oakpacific in that digital signatures, which would be trivial for banks to implement, on bank statements would immediately solve the problem. However banks are only using cryptography for the privacy functionality - they are not interested in non-repudiation of messages, even though it would be helpful to customers for a lot more than Bitcoin, it's not useful to them so they don't care. But I see that discussion as a tangent since we are not going to change bankers minds, we just have to get rid of their archaic system.

Actually it was just an example. Since smart contracts in OT contain scripted clauses, this sort of logic is customizable. Therefore the market will be able to determine which contracts work best for which purposes. (And create the contracts they need.)

If it's completely impossible for Alice / Bob to verify whether a SEPA transfer has been successful, then reputation systems (I believe) will fill the gap. (Though I would think that Bob would have access to an API to verify whether he received the funds.)

For example, instead of routing your transfers through "any ole person" you might prefer to route them through a more trusted party, such as a "gateway" (to use the Ripple nomenclature) -- although in OT that would not be someone issuing credit, but rather, someone buying/selling coins or colored coins. Perhaps 'Jorg' is just one of such services. Also on OT, that Jorg will not be operating a server but rather, using one, just like any other user.

Perhaps someday soon, 'Jorg' will just be a bank himself.

Yes, I've thought about this stuff before. Reputation systems are good for lots of little transactions, but there is a subtle but important problem with this approach.

First, decentralization always breaks if the cornerstone of the system is trust in individuals/nodes/people. That's exactly how the banking system came about. People with more and more money, and more and more power, get more of the money and power because they're the only ones you trust to keep your money. People's trust concentrates in those "nodes". This is what we have to avoid in our P2P solution.

We need to make it so the trust is in the protocol itself. This requires public verifiability of transactions.

It's good that the contract is customisable, but if that ends up meaning that we only transact with trustworthy nodes, we get centralization.

This is a good point, and ultimately the answer will lie in what kind of information can be queried from SEPA and other banking APIs.

Yep. You might be interested in what we're discussing here:
https://bitcointalk.org/index.php?topic=173220.new#new

Looks great! I will definitely bookmark it.

Ok our big goal its to descentralize absolutely our alternative economic system.

we have bitcoin + opentransactions + bitmessage,

but i think that we need two more pieces to complete this alternative system, because the global power system its attacking
the form that we change dolars/euro/... to bitcoins; and the fiat as a virtual currency are always connected to a nominal bank account controlled by the central banks.

1. A home version of bitcoin ATM.

Yes, perhaps sounds crazy,, but if we want to change the world, we need to think also about this crazy possibilities. A system by the way people could diposit fiat currencies to exchange for bitcoins from their home. So, a really p2p alternative to the banking system.

I imagine a little atm machine  connect with your cumputer where you put your bills, in order to be changed in the p2p exchange. When fiat is exchanged for bitcoins,
the atm system, blocks your possibilities to get the bills.


2. A p2p courier system to do anonymous bills exchange

To complete the bitcoin ATM home version, we need a p2p courier, that move the bills between diferents homes to adapt the exchanges between their p2p fiat accounts...Perhaps a cryptografic system could link the courier with the home ATM in order to do segure transactions...


So, i mean... we need to pierce the anonymity and decentralization to the physical world!

If people are interested perhaps its possible to create another post about this questions!

Nice, that made me think of this old thread : https://bitcointalk.org/index.php?topic=6279.0

I have a quarter of a bitcoin lost in a ripple/gateway transaction.  If I get it back I'm donating it to Open-Transactions.  I think ripple is great.  It's still a bit beta, but it works pretty well.  And I think it has a reasonable likelihood of adoption (I think its centralized nature will appeal to the establishment, and it has a bit of a marketing machine as it if a for profit company).  OT is so much better though.

I've made a number of attempts at getting OT running over the last 6 months.  The last time I was mostly successful, but still couldn't connect to the digitalis server.  I don't remember what the problem was.  I think I was unable to register a nym.  This is great news about federated servers, but at the moment I'd just like to see one or two running stably.

FYI the digitalis server has started using usage tokens -- so you will not be able to transact on that server without first contacting knotwork and asking him to give some usage tokens to your Nym.

I suggest for testing purposes, you run the localhost server (or contact knotwork and get some usage tokens.)

Unfortunately, this is not closer to the singularity, but farther away from it than Ripple. Why would we go to offchain transactions with more moving parts when we have a far superior fully integrated platform? Ripple does more than just solve the "multiple currency" transaction problem - it provides a more efficient validation and confirmation ledger platform. Mining is unnecessary and inefficient in the long run. We will see higher and higher transaction fees as Bitcoin adoption increases if the block size does not increase. With so many systems and so many moving parts and bottlenecks, a Bitmessage/Open Transaction/Bitcoin build appears inferior from a Universal standpoint to an integrated Ripple platform. 

It's almost like - since Bitcoin is not going to scale well without transaction fees and wasted energy let's just keep building on top of the flawed protocol and start shifting load to more abstract layers. The problem here is that once a lower layer fails all the upper layers fail as well. You are now making the machine more complex than it needs to be - more inefficient with more moving parts. I now have a lot more trouble programming for and around this machine and building on it more since I need to take into account more moving parts, each which has a chance of breaking. This is not good engineering. Good engineering is fixing all the core problems and embracing the new system that you built, not building a house on top of a cracked, unstable foundation, but replacing the foundation.

Lol yea bitmessage is cool

My family has been building houses and shopping centers for many generations. If we reexamined a foundation we had poured, a foundation we had put blood and sweat and tears into, and that foundation was flawed, we repoured. While it is tempting to continue to build on that flawed foundation, perhaps add some arches and redistribute the weight of the house horizontally, the building would eventually fail. I tell you what, our houses and buildings have withstood the test of time. Don't let crypto-currencies die by building on a flawed foundation and ruining the reputation of crypto-currency. Break up the concrete, recycle that concrete, and transfer that value of the concrete and the experience to a new foundation.

Oh yeah, sure. The traditional banking industry did splendidly without mining.
Thus mining is unnecessary. Just trust your favourite banker, or payment network company.
If in doubt, use a legal system to enforce the trust.
Simple and sweet.

Sorry Datz, the bullshit about your family's blood, sweat, and tears and foundations and all that... didn't do it for me.

I know you were going for the whole "emotional persuasion" job but it did not bring tears to my eyes.

I love how you talk about bitcoin's scalability (https://en.bitcoin.it/wiki/Scalability) as if what you're saying is self-evident and no one has ever discussed scalability issues before, or that everyone has accepted that it is not scalable. This couldn't be further from the truth.  I hope that lots of silly newbies read your post and believe what you say about Bitcoin's scalability, so that in the future they will eventually be corrected and will learn a thing or two about critical thinking. You are doing good in the world without even realizing it!

Scalability will be a piece of cake with Bitcoin. Sure, the protocol isn't anywhere near perfect right now, and there are still some projects to be finished before we're there (blockchain pruning, fully validating lite node that requires 0 trust and 0 centralization, etc) but these are all concepts that have been fleshed out and just need more "blood sweat and tears" dev time just like your family building those shopping centers. This is software in beta testing. We are STILL building the foundation, of a type of structure that has never been built before in the history of mankind, a technological and engineering marvel. Ripple? Ripple might have a few problems sorted out but they are not even anywhere close to decentralized, not open source; I won't even consider glancing at Ripple until it is both! LR just had millions of dollars of client funds seized. Some of them ML and nefarious criminals, but some honest folks. Ripple could be shut down and all client funds seized, in its current state. Let's not pretend we're comparing anything even remotely similar.

However, let's NOT let this turn into a RIPPLE VS BITCOIN thread (you started it ;D). Take your propaganda  elsewhere :D :D :D (and yes, it reads exactly like propaganda, cut out the blood sweat and tears hard working brick and mortar strong foundation bullshit, it sounds like you're speaking on a political commercial targeted to a group of 50-75 year old American men in the steelworker's union)

Actually I was not going for ethos or pathos here, but logos. Logically, I would not build on a fundamentally flawed structure, no matter how much work I had put into it, no matter how much I was emotionally invested in it.


Scalability of the Bitcoin protocol is an issue. This is why we have implemented transaction minimums in client updates in response to Satoshi's dice and transaction fees. The Bitcoin protocol can only handle so many transactions per second and requires inefficient mining to facilitate transactions which opens up a vulnerability unto itself. This is why we have posts advocating "off chain" transactions. Any third party can buy 51% of the computational power and wreak havoc. Bitcoin requires a balance of opposing forces and may easily break under the right stress or the right conditions. There is always a tradeoff.


Contributors mentioned Ripple and the death of Ripple over ten times on this thread. I did not start this line of thought. I am talking to every bitcoiner and miner who is emotionally attached to the protocol.

Go for it, rebuild bitcoin from the ground up. It is an open source protocol operating in a free market ... just no need to spam a whole lot of nonsense on this thread .... go and start breaking concrete, get back to us when you have built your new mall we should all be shopping in (XRP only accepted I suspect).

Appreciate the support, but the mall is already built.

Perhaps, but I'm still not 100% convinced. For example, what's the answer to this question (https://bitcointalk.org/index.php?topic=176940.0)?


I agree with that. And that's why the block size limit has to be lifted. Even if it implies a chaotic hard-fork due to the stubborn ones who want to cripple Bitcoin.... so be it. The majority will prefer the scalable and affordable Bitcoin, not the SWITF2.0 one.

The forkers would be ignored and cut out.

Since every validation must be signed, it is blatantly apparent who is lying.

Liars or forkers are automatically detected and if they lie enough to meet a threshold can be automatically cut out of the network.

It is all reputation based - so if I have a reputation as a good validator people will choose to trust my node as a validator. This is how the Ripple protocol differs from the Bitcoin protocol.

With the Bitcoin protocol, any third party can mine on the network and exert control. Blocks must be confirmed by miners - thus miners and computational resources are always necessary for Bitcoin to properly function and must always be incentivized. Spamming the block chain is always an option without proper disincentives which inconvenience transactions and defeat the purpose of crypto-currencies even though they may still be better than alternatives.

With Ripple, the main members of the network may choose to accept or ignore validators. Ripple includes a framework for automatically detecting nodes going against the consensus. In the early stages, most validators have vested interests in Ripple's success. Thus, Ripple allows for fewer validators, less computational power, and decentralization/distribution. Imagine taking out all of the spammers, "dust bunnies," and bad guys from the Bitcoin protocol and eliminating mining. How much more efficient a protocol would it be? Even if 80% of validators that somehow managed to gain trust decided to fork Ripple dishonestly the major exchanges, institutions, and people who matter in commerce would cut them out immediately and would never trust them again as validators based on their signatures. The same cannot be said about Bitcoin.

What's more is that Bitcoin cannot change it's core without becoming an entirely different protocol. Building layers on Bitcoin may alleviate load on the block chain, but after the deflationary period this will only result in less fees for miners and less computational power, making Bitcoin vulnerable to the 51% attack as mining for bitcoin creation becomes less profitable. Maintaining the block size as adoption increases will result in higher fees in order to increase incentives for additional computational power in the network to confirm transactions. If we increase the size of blocks we move toward centralization and encounter some of the same problems (https://bitcointalk.org/index.php?topic=208200.0). Even then, we still face transaction size limits in order to reduce spam. Imagine clients not paying a transaction fee and building up thousands of fee-less blocks which may take forever to be confirmed by miners since fee-less blocks do not pay. Even if Moore's law results in better connectivity and speed, we are still wasting all this electricity and processing power on mining just to prevent the 51% attack. Ripple helps solve these problems and is a happy medium.  

I would rather embrace a distributed, technically unified protocol that will transition from centralized to decentralized than a fragmented, bottlenecked protocol which will transition from decentralized to centralized. Ripple keeps things simple and allows for more functionality in one decentralized API.

Thanks for the info about Ripple. I am interested in learning more about it, just not here.

Two points:

1 - You are making Ripple sound like a replacement for BTC when the designers say it is a compliment to it. Seems like BTC is doing well and with so many XRP's out there and the owners owning a ton, I don't see value in that.
2 - Could you answer this in a Ripple thread since this thread is about Bitmessage. This is really annoying from the Ripple guys, always jumping in BTC threads. If all the cryptocurrency guys did that, this place would be a big mess.

Thx,
IAS

Datz, I answered your post in the appropriate thread. If you could transfer the discussion to that thread I'd appreciate. Thanks.

+1  ::)

Bitmessage is great  ;D

Only to comment about a new post  to focus in a peer to peer courier network:

https://bitcointalk.org/index.php?topic=166420.new#new (https://bitcointalk.org/index.php?topic=166420.new#new)

all the people interested are welcome!

what does bitmessage do that i2p and freenet cant do?

Please read how I am using bitmessage, in the OP (see pastebins), and tell me exactly how to do those same things in i2p and freenet. I would like to know.

Also FYI the whole idea is that bitmessage could easily be swapped out for other discovery layers.

I'm so happy to hear that ripple has everything baked right in.  Could you point me to the APIs for issuance and management of blinded cash tokens?  I seem to have missed them somehow...

Of course we should all use Ripple. What could be the possible downside to using a system of debt with a closed source and where the actual 'ripples' carry value in themselves and are all pre-produced to the tune of 100 BILLION and handed out to developers and company owners so that they can sell them and get rich..

Oh wait, did I just answer my own question?

With this idea the exchanges are still centralized right? still points of failure. There is no reason why we couldn't have this totally decentralized.

why not just design a program that could scan the blockchain of bitmessage for buy and sell offers that match specific syntax and aggregate and display that data in a way that is easy for users to interpret. Then have built into the program tools that could be used to easily arrange for the creation of a risk fund (explained here http://nashx.com/about) by way of a multisignature transaction on the bitcoin blockchain. this way you can safely make transactions person to person with people you dont know ANYTHING about with out the need for any help from any third parties (unlike with the chaum bank provider)

You could even design algorithms to extract up to date prices for each market from the bitmessage blockchain.

BTW, I like your proposal and I think you should code it.

However, in the case of OT, the servers are not failure points. If the users broadcast a discovery for a certain server and it doesn't work, then they can just use a different one instead. Federated.

Personal clouds communicating via XDI are helping to solve the p2p discovery problem.

https://wiki.oasis-open.org/xdi/XdiDiscovery  (https://wiki.oasis-open.org/xdi/XdiDiscovery)

http://respectnetwork.com/development/ (http://respectnetwork.com/development/)

I had some questions before I read this thread (14 pages!), but I didn't find satisfactory answers.  Having read through the thread, I will try to show why I think they are important questions before asking them...

The banks over the last several centuries have issued receipts that were redeemable in return for commodities.  Some started issuing receipts behind which there were no commodities.  Then government said "that's Ok, we'll do it too so no one will ever have a reason to redeem for gold."  This is echoed in FellowTraveler's statements about colored coins.  If you don't know what happened after that, Google Rothbard banking, and the meaning of "fiat".

Part of OT's protection from this is the theory is that we will create "basket currencies" so lots of issuers are involved, and if one defaults, we'll be ok.  So I have a prediction to make, which could be prevented, maybe.

The same sociopaths who currently run the world will create lots of Nyms on OT Servers, untraceably, and issue digital currencies for all kinds of stuff.  They will happily redeem whenever someone requests it - for a generation or two, or perhaps just a couple decades or even years, depending on how short they can cut the average attention span with their government schooling and the mainstream media.  When they are ready, just as they were in 1933, and again in 1971, and then again when they passed The Authorities Robbing People (TARP), they will, in the subtlest way possible, stop those redemptions.  Some who have their savings in colored coins or various other digital currencies issued through OT servers from those sociopaths, those who see what's going on, will go to their coercive-government-sponsored banks and/or court-systems to make an attempt at recovering some of their life savings, and they will succeed.  They will have lost only a portion of their savings, and that portion will once again be in the hands of the same sociopaths who have it today through the efforts of the same depraved and immoral banking system that inspired Satoshi Nakamoto to invent bitcoin.

The problem of a person or group of people establishing a pattern of being trustworthy and then breaking that trust (and, while governments are still around, leveraging the brute force of the state to protect themselves) will NEVER go away (governments might - see voluntaryist.com), and there are very few systems in the world that handle this ugly feature of our race very well.  Bitcoin is one of them.

Open Transactions appears to me to be capable of handling it, but a fool is born every minute (probably more often now, thanks to the consumption of processed food - look up Weston A. Price if you're curious), and those fools are the foodstuffs of the sociopaths, and OT could make a nice oven for to cook them in (just as banking and fiat has for a century).  If OT is going to elegantly handle the attraction of those sociopaths, I think it will have good answers to my questions.

My questions are in what I sent to the Open Transactions team a day or two ago:

I do know a little bit of programming. I used to play around with python, invent little mathematical challenges for myself and then code a function that could be used to solve it out for fun. But i have no idea how to make something that involved, or even what i need to learn in order to know how to make something that involved. multiple tiers of ignorance going on here.

@dscotese

The whole point here is not to save fiat currency. If you're going to hold fiat-backed tokens, well, you're accepting all the problems you talk about. The whole point here is to improve considerably the process of exchanging fiat for bitcoins. Bitcoins do no suffer the problems you cite: you can be cryptographically sure your "bank" has your coins. But unfortunately we need - and we'll keep needing for a long time - to exchange bitcoins for fiat and vice-versa. If we could render such process much more reliable and censorship-resistant, that'd be a good thing, wouldn't it? That's the point here.

And then there's more. OT can be layered op top of BTC too, totally bypassing fiat. It would add instant confirmation, totally untraceable digital cash and lots of more advanced financial instruments. .

Indeed. This is true for all currencies except for purely virtual, blockchain-based currencies like BTC and LTC. (No real-world redemption is necessary for such tokens because the token itself is all there is.)

Whereas if a digital currency is "backed" with anything (gold-based, dollar-based, etc) then it becomes inescapable that there must be some form of "issuer" who is holding the gold.

...Which implies counter-party risk.

Open-Transactions was originally meant for such gold-based currencies. The idea was never to eliminate the risk of the issuer, which is impossible, but rather, to devise mechanisms for the distribution of that risk in order to create a user-centric system. This is the same concept, BTW, as the provider-independent Tahoe-LAFS project. (https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst)

"Tahoe-LAFS is the first Free Software/Open Source storage technology to offer provider-independent security. Provider-independent security means that the integrity and confidentiality of your files is guaranteed by mathematics computed on the client side, and is independent of the servers, which may be owned and operated by someone else."

The original idea with Open-Transactions was to implement this same concept for money.


If someone is holding your physical gold, and then he refuses to give you the gold back, then you have lost your gold. This, as I said, is absolutely inescapable except for purely blockchain-based currencies like BTC.

...So what can you do? There's always the "Jim Bell" solution, or the "crappy court system" solution. Or the "insurance" solution. Or the "reputations tracking" solution.

What I settled on with OT was basket currencies. That is, to distribute the risk of a single currency across multiple issuers, such that the loss of a single issuer does not result in the total destruction of value, of that currency.

Another piece to this is jurisdictional arbitrage. Which is to say, these multiple issuers should all be located in different jurisdictions. To their credit, the Ripple team is exploiting this mechanism also, in their own way.


I would think that the issuers are more likely to be publicly-known (by their choice), while the users would be the ones more likely to hide their identities.

If you give your gold to an anonymous entity, you are taking a much larger risk than if that entity is publicly-known. Of course, it is your choice to do so, and the free market will have to take its course.

So I ask: why would you choose an issuer who is anonymous, over one who has an agent available to receive service of process?


There is no such mechanism within OT itself, however, this is outside of the scope of OT.

A certain Nym ID is the same across all OT servers. Thus, there's nothing preventing tracking mechanisms from popping up -- reputation-tracking websites for example, or some form of web-of-trust. But I think it would be better to use software especially suited for this purpose -- perhaps Monkeysphere?

One point though: The OT crypto is currently implemented using OpenSSL, which is able to verify identities through their certificate authority / PKI.

However, all the OT crypto is used through an abstract interface, the OTCrypto class, which is then implemented to use OpenSSL calls in a subclass called OTCrypto_OpenSSL.

It would not be difficult to make another subclass called, say, OTCrypto_GPG, and you could thus entirely swap out OT's crypto (currently based on OpenSSL) to use GPG instead.

I believe web-of-trust is available through GPG?  So that might be one solution that could be built directly into OT itself, with little trouble. Then it could potentially verify the Nym's credentials via web-of-trust instead of CA / PKI.

But otherwise, as I said, it's probably better to track this outside of OT, using some other software which is especially designed to implement such functionality.


The risk of issuer-default is inescapable for any "backed" currency. We cannot entirely eliminate risk; we can only devise better and better systems for the distribution of that risk in a wallet-centric way.

You are entirely correct about this, of course. The market will have to make certain decisions and they will take things such as jurisdiction into account. (As well as posted bonds, insurance, auditing protocols, reputation, etc.)

===> See this article. (http://pelagic.wavyhill.xsmail.com/Private_Digital_Economy.html)


I have recently added "credentials" to Nyms, meaning that Nyms can have master credentials, which are able to sign sub-credentials, which are then used for actual transaction signing. I have not yet added API calls for revoking sub-credentials, however they are coming.

If your master credential is based purely on a key pair, and then you lose the private key, well -- you are screwed. (Some would say this is a feature.)

However the idea is that your master credential could instead be based on a cert, issued by a traditional certificate authority. This way you could just get the cert revoked and have a new one issued in such a situation. (The risk, of course, then becomes the certificate authority itself, whom you must trust not to take over your Nym and steal all your money.)

A third concept (my favorite one) is to use the blockchain itself to replace the certificate authority. A certain Bitcoin address could send a transfer (say a satoshi, to anyone) and store a hash in that transfer. (The hash of a master credential...) This way, if you ever wish to revoke that master credential, you just send a new transfer with a new credential hash in it. (The verification process would just look at the hash contained in the most recent transfer for that BTC address.)

This might seem like "turtles all the way down," since the power over that identity just gets transferred to a new private key (your Bitcoin wallet) which again, must be protected against loss. But it does provide a universally-verifiable medium for credentials and revoking.

You might ask, why not use Namecoin instead of Bitcoin, for storing these credential hashes? The answer is because Namecoin names expire, since they must be human-readable. In my case, I don't need human-readable -- just unique. Therefore, I prefer to use a system which does not expire. (Namecoin is still very useful as a DNS replacement, however.)

So my ultimate answer is, I plan to use Bitcoin itself to replace the Certificate Authority.


Currently nothing like this is built-in, but it would be easy to add. You could also secret-share your BTC private key (used for issuing new credentials, in the above example) and then give the shares to various trusted family members. After all, as you noted, you wouldn't want to die and leave your wife destitute and starving on the street.

Destruction funds utilizing the principals of the nash equilibrium is a MUCH better solution to the trust issue than reputation imo. With a trust based system different liabilities from different people have different values, this makes the asset that corresponds to these liabilities into a heterogeneous good. By utilizing the nash equilibrium we can homogenize these liabilities into a uniform homogeneous good. In order to discover an objectively valid price for a good that good must be made homogenous. Imagine if i asked you what is the price of one acre of land. it would be a ridiculous question because land is a heterogeneous good.

I've been meaning to read this thread all week and I finally got time over the last couple of days. I have to say, I'm very impressed!

I know the original post was about BitMessage integration with Open-Transactions, but this is the first time I have read about either technologies. I've read/heard a lot about Ripple (in original and new form), but OT had some how slipped past me so far.

OT has clearly been well thought out. Having read all the posts and found fellowtraveler's comments very helpful, I am now rather excited about this.

The concept of detaching issuers and users from OT servers is brilliant. Having OT servers just acting as blind processing nodes is a great idea and I didn't even realise it was possible!

Detaching issuers from OT servers strips the former of their power to abuse their position. IOUs cannot match this ability.

Detaching users from OT servers strips the latter operators of their power to abuse their position. IOUs cannot match this ability.

I like the way no new currency internal OT currency is needed either, with Bitcoins providing a useful store of value at the core. This seems to be building on top of what already works well.

It will be interesting to see how readily people will leave Bitcoins or colored coins within the OT system. I can certainly see people trusting OT far more than current exchanges. Considering how users and issuers are also detached from OT, this would further encourage trust.

The Holy Grail in 7 easy steps:

1. Imagine an issuer, who issues a Euro-based currency in the form of colored-coins on the blockchain. (Hereafter, let's refer to these as "Eurocoins.")

2. This issuer buys and sells his own Eurocoins, in return for Euro bank wires. These wires can be fully AML/KYC compliant -- and most users will never have to deal with the issuer directly anyway. Why not?

-- Because as long as the issuer serves as the "redeemer of last resort" then users will rarely have to sell Eurocoins back to the issuer, because instead, they can sell and buy them directly from each other.

3. Users then upload Eurocoins (and Bitcoins) to Open-Transactions servers. Except the coins don't go directly to the server -- instead, they go into a multi-sig voting pool on the blockchain itself.

-- This way, the OT server can issue units based on those Bitcoins and Eurocoins, but cannot steal those coins from the pool. (Also, internally, the OT server is unable to change balances or forge receipts.)

4. Notice that the Eurocoin issuer is now entirely divorced from the transaction server where those coins are traded. That is, the issuer may not even be aware of all the servers that are trading around his Eurocoins. (Just as the Federal Reserve has no liability for what happens to individual dollars once they have been released into the wild.)

5. Once Bitcoins and Eurocoins are issued as units inside Open-Transactions, users can safely trade them on markets, as well as use financial instruments--cheques, cash, basket currencies, smart contracts (including escrow), etc. Instant clearing can happen here. All the normal OT capabilities.

6. Since OT can perform escrow, for example, Alice can send Eurocoin units (inside Open-Transactions) to Jorg, in return for a SEPA transfer from Jorg to Alice's legacy Euro bank account.

-- Notice that Jorg is not an issuer, and he does not operate any servers. He is merely another user, who buys and sells colored coins (via OT escrow.) He does not hold any money on behalf of anyone else. This is in contrast to Ripple, where the gateway also operates a server, *and* also issues credit (or holds money on behalf of those who do.)

7. The integration of Bitmessage as a discovery layer, makes possible the wiring of units from one OT server to another, in addition to cross-server discovery for the purposes of market exchange or fiat transfer. (See the original post in this thread.)



Now what capabilities do we gain, as a result of all this?

--- We have currency issuers who do not process any transactions, and in fact are entirely divorced from any transaction processing. These entities can be entirely KYC / AML compliant.

--- We have users who can convert any currency into any other currency, on OT markets.

--- Our users can then convert in/out of legacy banks without dealing with the issuers directly, since they can just buy/sell colored coins directly from other users.

--- We have transaction servers who can operate anonymously, yet who cannot disappear with the funds, and who cannot forge the receipts.

--- We have cross-server trading, and wiring of funds.


May a million currencies bloom!

The first step that I'm skeptical of is where an issuer issues colored coins and promises to redeem them on demand, but without tracking the identities of their owners as ownership changes via the blockchain.  Wouldn't regulators argue that colored coin issuers are legally required to do this?  Aren't they otherwise essentially issuing bearer bonds, which seem to be de facto illegal now?  The functional similarities between such an issuer and, say, Liberty Reserve are somewhat discomforting.

Also, it seems by your logic that the only thing protecting the OT token issuers themselves from falling under regulation is potential anonymity provided by the blockchain's obfuscation of the colored coin owners.  But the above argument seems to suggest that the OT token issuer's identity must be known by the colored coin issuer for them to remain in compliance with regulation, and so the OT token issuer isn't "entirely divorced" from the colored coin issuer at all.

I actually DID recently develop a concept that can be used to create decentralized exchanges.  It's very similar in structure to Bitcoin.

https://docs.google.com/file/d/0BwUFHE6KYsM0ZkxLVmFwbXQ3ck0/edit?usp=sharing

But it is just a concept, right? There are tons of P2P exchange 'concepts' out there .... code, or it didn't happen.

Besides when you have 50 or 100 identical exchange servers performing identical signatory tasks ... is that really still centralized? I don't see how.

you obviously didn't read the paper.

a detailed discussion can be found here: https://bitcointalk.org/index.php?topic=212841.msg2280478#msg2280478

of course it's not centralized, it's peer to peer.  You could for instance run a currency from your cell phone.  Many of the claims made on this thread re. OT don't really make much sense, and the discussions appear distorted- seems to be common whenever the subject is Open Transactions.  It's almost as if there is a internet marketing(spam) expert behind all this.  Adding Bitmessage to OT does not make it Peer-To-Peer.

There's nothing at that link.

are you sure?  seems to work for others.

you can also download it here:  https://groups.google.com/d/msg/bitcoinx/oAERXr17zII/5O5EDkkWcpwJ

I've thought about the possibility of using the blockchain to contain the structure of a self-governing web of trust. Have you given any thought to this?

My idea is that you'd start off with a large odd-numbered founding group who would all prove their real world ID to each other and then they would initiate smaller groups by "passing the baton" (or issuing a cert) of some kind to them so that they could then initiate other groups, always being sponsored by previously validated groups, and so on and so on.

The "baton" could be a password/key, or colored coins, released through a voting mechanism. I understand that Bitcoin also has many latent features for doings all sorts of interesting transaction types which amount basically to contracts and/or mini programs. And since Namecoin purports to do stuff like this, I imagine you can just use the original - Bitcoin.

I was thinking of a cell structure for the WoT where only a handful of people in the network would have access to your ID and it takes a vote of those trustees to reveal it to another member who prevails in a case against you. There would be a public organizational tree on the blockchain so that a plaintiff could apply to your sponsor group to file a complaint. This sort of action would be a last resort and only used to deal with the real bad actors after other mechanisms failed. The ultimate sanction would be to blacklist your real ID from the network. The knowledge of this backstop of accountability to one's peers will motivate everyone to play nice and safeguard their reputation - because ultimately it's YOU and not some dime-a-dozen pseudonym that's vulnerable to being exposed.

The potential for self-governing mechanisms with open P2P and crypto are really fascinating. I think a WoT is the best solution for carrying on serious free-flowing commerce long term. There's nothing like the threat of WKWYL (We Know Where You Live) to force people to play nice. The ability to have trusted certification of an ID, even if it's just vouching for the fact that some pseudonym reflects a unique real person who was validated and can only register once, is a very powerful way to ensure the success of a network of traders, IMO.

Are there any real technical barriers to encoding a WoT on the Bitcoin blockchain and/or OT?

I suggest people take "bluemeanie1" with a grain of salt. (https://bitcointalk.org/index.php?topic=212841.msg2282547#msg2282547)

-- Then again, remember that this issuer can remain fully AML/KYC compliant.

-- Meaning they can demand the same information for all bailments in/out, that MtGox demands.


Well this is a good point, and only a lawyer and/or test case will tell for sure. It might depend on the jurisdiction.

This also might apply to miners. After all, they are also releasing a currency into circulation which is traded as "bearer". In fact, FinCen has already stated that people who create virtual currency and sell it for money -- must register as money transmitters.

This also applies to BTC exchanges. After all, exchanges are also expected to follow "know your customer" regulations for all bailments in/out of the system. Yet they also do not track ownership changes for bitcoins that circulate outside of their system, even though they follow KYC/AML for bailments in/out.


...Until they go to the issuer for redemption, at which point they must identify themselves according to KYC/AML regulations.


The colored coin issuer doesn't issue onto the transaction server, he issues onto the blockchain. So by your logic, he must know the identities of all the miners who process that system. In fact, by that logic, all miners must know the identities of all other miners, in order to stay compliant.

In my own scenario, it's the users who issue the colored coins onto OT transaction servers. I say that the currency issuer is "entirely divorced" because he hasn't issued the coins onto any transaction servers at all -- although he has no way of preventing others from doing so.

I think you have raised some good points, although I think if they are true, they will also apply to Bitcoin miners, Bitcoin exchanges in general, and even the Federal Reserve itself. It will be interesting to see how the courts, and the various jurisdictions, deal with all of this.

This is not true, I think. Technically you can issue a currency without either operating a server or issuing credit.

Sorry, I meant to say "gateway"...

The post is now fixed:  https://bitcointalk.org/index.php?topic=212490.msg2324287#msg2324287 (https://bitcointalk.org/index.php?topic=212490.msg2324287#msg2324287)

It's likely that gateways will run their own servers, but technically they don't have to. They do issue credit, by definition. They don't even issue credit, people have to extend them credit. They hold money for others.

If you use OT for trading coloured coins, is there still an advantage to having separate issuers and servers?

-- If it's a colored coin, then by definition there is an issuer.

-- The reason for doing the transactions on an OT transaction server is to gain the benefits of OT, such as untraceable cash, instant transactions, markets, cheques, stocks with dividends, basket currencies, micro-transactions, destruction of receipt history, off-chain transactions, etc.

Therefore it seems that even with colored coins, there will be issuers and servers.

Sure, but what's the advantage of having the issuers separate from the servers? I'm not saying there isn't one, I'm just trying to understand the reasoning.

 do you suggest that?  You were the one who wanted to remove the thread.

 Meanwhile, you have absolutely NOTHING to show for your claims.  Im starting to suspect that you are sock puppeting here, Reddit, and other sources of information on Bitcoin.  This new "OT + BitMessage = Kingdom Come" seems to have been exactly timed at the release of my paper(which you keep claiming you never read, but also referred to numerous times).  Being that Chris can't seem to conduct himself without making personal attacks(this is the second time), he forces me to account for our work together, his plan to commercialize OT at the expense of the community, and his all round sketchiness.  Why does it seems OT is being discussed, but no one seems to know exactly what it does?  This doesn't sound like an open source project to me.  That's because it isn't one.  How many open source projects do you know that have no real users, appear to be discussed constantly on every subject imaginable, and no one seems to know how it works, and there is a company already formed to implement ideas using it?  Remember Chris was an spam marketer before he decided to become a digital currency guru, this is probably why he knows a thing or two about how to hide your IP, how Tor works, etc.  Just consider how many REAL people you know who claim to have used OT for something useful.  Many people I know personally were complaining about his recent spam initiative entering their space through a variety of vectors and how annoying it was.

 Meanwhile, all I am doing on here is talking about a completely free and open digital currency concept which Chris appears to hate with a passion.

 IT SLICES, IT DICES, IT JULIANNES, IT'S OPEN TRANSACTIONS(tm)!  now with P2P flavor!  buy now and get a free internet!

 of course we can say that OT does all these things.  We can also say a toaster does the same things as a 747 if we just add a fuselage, a jet engine, wings, and a few other features.  We would only have this scenario if someone were trying to SELL us the toaster.  That might provide you with a hint.

do not trust this spam marketing leprechaun, I unfortunately did.

Re: bluemeanie1

As long as you are posting in my threads, I think it's important that people know your true motives. (https://bitcointalk.org/index.php?topic=212841.msg2282547#msg2282547)

I am also saving a record of all of your false public statements.

For the record: I do not, nor have I ever, engaged in spam marketing.

Why don't you let him start his own thread and delete his posts here?

This thread is not self-moderated, so I can't delete posts here.

Also, I don't want to stoop so low as to conduct censorship. (Even against trolls.) I prefer to allow the forum moderators to do so.

I will not be engaging him tit-for-tat, however -- I will just refer people back to my official statement on the matter.

remember those ads you would get about 2 years ago for books about how to pick up girls?  that was Chris.

This guy is referring to the fact that I am the author of The Mystery Method.

I have not often mentioned this in the digital currency community, as I am rather well-known, and I have preferred to allow Open-Transactions to stand on its own merits.

However, I never spam-marketed the book, as it was published by St. Martins Press, and is sold in book stores and on Amazon. I'm certainly not ashamed of my success.

Why would Joshua Zeidner lie publicly, calling me a "spammer" and create unnecessary liability for himself? His true motives. (https://bitcointalk.org/index.php?topic=212841.msg2282547#msg2282547)

Good question. Consider it in three layers...

Layer 1: the issuer directly operates the transaction server. (The guy who holds the gold, also processes transactions between the internal accounts.)

This applies to E-Gold and (I believe) Liberty Reserve. The problem is, if you process the transactions, then you are liable to monitor them and report them. This liability results in the seizing of the gold.

Layer 2: the issuer issues his currency onto a separate transaction server.

This applies to Loom, Truledger, Voucher-Safe, and even OT, if you use it that way. This represents an improvement, since the issuer is no longer directly processing any transactions. The problem is, violence can be used to force the issuer not to use specific servers.

Layer 3: The issuer issues his currency onto the blockchain as colored coins.

This is what I've proposed in this thread. This way:

-- The issuer cannot control which servers the users choose to transact on.

-- Thus: The issuer cannot be forced by any threats to choose which servers the users may transact on.

-- The issuer may not even be aware of which servers the users may be using to transact on.

Of course, the issuer still must be fully AML/KYC compliant, since he is sending/receiving bank wires as he buys/sells his own colored coins.

Is there a way to prevent the need for voting by somehow putting the logic inside a Bitcoin script, perhaps with new opcodes if necessary?

I assume you are asking about the voting pools... My plan is to use the multi-sig bitcoin script, on the blockchain itself.

Can you please be more specific about the logic you have in mind?

Here's my own:

1. The user who wishes to transact on OT, bails his coins into a voting-pool (by sending them to a recipient on the blockchain composed of multiple BTC addresses.)

2. The server verifies that the coins are in the pool, and issues corresponding units inside OT to that user.

3. From here, all transactions occur off-chain. (So far, no voting is necessary...) Perhaps a thousand transactions occur at this step.

4. It's only when the user wishes to bail back out of the system, that a vote of the pool members (the other servers) becomes necessary.

5. The user himself plays no part in the actual vote, since his balance might be quite different on the way out, than it was on the way in.

I'm still trying to figure out how your system works, so the question may turn out to be meaningless. But I was wondering if there is a way to let a Bitcoin script verify that a person is authorised to redeem BTC from a backing account when presented with appropriately signed evidence.

I don't think so -- because the voters must verify OT-specific information before voting.

(Like verifying the user and server have both signed the bail-out request.)

This is probably why no one else is using voting pools yet, even though multi-sign is functional: because you need the OT side as well, to make it work.

However, if what you suggest is possible, then it will improve my system even more, so I hope such a thing is found!

so how long until this is an android app that replaces what'sapp?

I ask because i understend completely ZERO of this thread. All I want is an anonymous communication tool.

Can you explain how the bail-out request works? I recall reading detailed human-language transcripts of all the transactions that are involved, either on your wiki or on some of the sites it points to. I don't have a good picture of the differences between OT on the one hand and Loom, Lucre, and all the other concepts it uses / borrows from.

Let's say that you and I form a pool. (Some of the money in the pool comes from me, and some comes from you.)

As you can see, if I perform a false bail-out from the pool, I have actually stolen from you!

...Therefore you have an incentive to only allow valid bail-outs.

Therefore, as a pool voter, your incentive is to verify that both parties have signed the bail-out request, and that the transaction server in question doesn't fail its own audit.

Thus, the pool itself acts as the "issuer" would have acted, if the currency had been directly issued onto the transaction server. (In terms of verifying the audit (https://github.com/FellowTraveler/Open-Transactions/wiki/Auditing) data.) That is, they audit each other, and they have an incentive to do so.

The process:

1. (The user might have bailed-in 100 BTC, and then traded 90 of them away, leaving 10 BTC in his account.)

2. When the user bails out, he submits a signed bail-out request for 10 BTC to the server, who counter-signs it.

3. They send a copy of this receipt to the other pool members, who verify it and then vote on the blockchain to release the funds.

What happens if the server fails to sign?

Well for example, let's say the server disappears entirely...

The user sends a recovery request to the other pool members, who verify the situation and then vote to recover your coins.

This contingency is actually the whole reason for having voting pools in the first place. The server would be unwise to do such things however, as he cannot steal the coins anyway (they are in the pool.) Plus, he'd instantly lose access to any future transaction fees, as well as losing access to all the rest of his legitimate share of the coins in the pool.

Your next question might be: what happens if the entire pool disappears? Answer: you're screwed.

This is why the ultimate distribution of risk must occur inside the wallet itself (for example, allocating your funds across multiple pools.)

We cannot eliminate the existence of risk, we can only devise better and better mechanisms for distributing it in a user-centric way. In fact, this philosophy underpins Bitcoin itself.

This concept of a provider-independent distribution of risk is borrowed from Tahoe-LAFS. (https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/docs/about.rst) Kudos to Zooko!

So what information does the recovery request contain, and what information do the pool members have to verify the situation?

"Help! Server Sam has disappeared! I need to get my coins out of the pool! Acct ID. Nym ID. Signature."


They have access to the audit data. See the auditing link posted above.

Very interesting stuff, it's going to take some time to digest all of this.

Just playing devils advocate slightly, but it would seem the coloured coins idea would work equally well within the Namecoin protocol. The coins themselves do not expire, so could be used as you suggest. The added bonus here, being, each issuer could have their own public/private uncensorable DNS identity cryptographically tied into their set of coloured coins.

Their DNS identity could then act as the entry point for all information about the company/stock/commodity or even as a trading platform. The problem with names expiring is negligible as they will expire after a fixed period (36000 blocks [ DO NOT POST SESC LINKS ] i'm informed[/url]) and could be set up to automatically renew before this period if the company/stock is still currently trading.

Thoughts?

Trying to install OT right now and ran into an int casting error. Think I might need to run it on a 64bit system is all. But I wanted to ask:

I keep seeing talk of colored coins which I had to research. I think I get the idea but as far as I can tell there is no working system for them yet. Just proof of concept. Would OT be able to issue these or would it only be tied to the exchange network the coin was colored on? Or is the dream to have an exchange tie in?

I like the possibilities this offers to devs and start-ups and hope to see a functional OT server pool soon.

Are colored coins even economical in 0.8.2? I heard some concerns that the stifling of dust transactions would effect them.

Let's assume that the smallest possible transfer is 0.00005430 BTC -- and let's assume a fee of 0.0005.

Therefore, a total transfer of: 0.00055430 BTC

As I write this, the last trade on MtGox was at the price: $121.50000 per BTC.

Therefore, 0.00055430 is (measured in dollars) worth a little less than 7 cents, aka $0.07.

Let's say that the above transfer is used to issue a colored coin with the value of 1000 Euros...

This colored coin could remain on the blockchain, but if you moved it to an OT server, you could break it up into 1000 units and trade them as individual Euros.

...From this point, you can trade in units of 1, or 5, or 20 Euros (etc) and you could trade these units with your friends for physical Euros. (Or, if you put 1000 of them together, you could go directly to the issuer and obey KYC / AML and get a bank wire.)

Coloured coins can always go on the namecoin blockchain where they get almost as good security because of merged mining. Imho, that is the best place for them as it offers other possibilities, tying identifiers and credentials to coloured coins being the most obvious, but others also.

You could either waste the arbitrary amount of 5430 satoshis for every colored coin, or, with the collaboration of a single mining pool, you can get colored coins transactions through even with 1 satoshi outputs. Obviously miners would request some fee to be paid, that's why I wonder if an alternate chain wouldn't be a better idea as fees could be paid with the tokens themselves, but anyway, colored coins on the main chain are already implemented, an alternate chain would have to be created from scratch.

If you think 7 cents is too much to pay, to move 1000 Euros (see my example above) then you are really going to hate PayPal. (Also note that it could be 10,000 Euros, or any amount, really.) Also of course, the issuer will have a fee for doing so, and that fee will include the cost of the bank wire.

However, your ideas are sound. It doesn't really matter to me which way it goes, as long as I have access to use those colored coins.

I just sent Bitmessage.org to a friend of mine on the front lines in Istanbul. He has reposted it to twitter as we speak. This could be a watershed moment for Bitmessage! If people can try and publicise Bitmessage.org as much as possible, share on twitter/facebook/etc we can give people in repressed regimes everywhere the ability to communicate!

ill download it, how do i message you?

here is my address BM-2DCLDXTLT4RH6Wb2xpHspHFN3fHghVdsLn if anyone wants to subscribe to it ill make sure to write something periodically for the hell of it  ;D

this might go down in the history books.

Announcement:

===> I have just posted a BOUNTY for this. (https://bitcointalk.org/index.php?topic=225954.0)

So if OT relies on the Block Chain why use Open Transactions at all?

How does Open-Transactions benefit Bitcoin? (http://bitcoin.stackexchange.com/a/2710/309)

does anyone besides yourself(who is not anonymous) support your claims as to what this software does?

TLDR
Quick question

Would this "The Holy Grail" stabilize BTC in such a way where each fiat has a colored representation on the blockchain?

I'm going to post my final answers to this thread, and lock it.

I've already put up a bounty to get the necessary UI coded. (https://bitcointalk.org/index.php?topic=225954.0)

(If there are more questions, feel free to start another thread.)

------------------------------------------------------------------


Yes, see this reply. (https://bitcointalk.org/index.php?topic=212490.msg2238335#msg2238335)

Also, this reply. (https://bitcointalk.org/index.php?topic=212490.msg2326913#msg2326913)

As well as this reply. (https://bitcointalk.org/index.php?topic=212490.msg2239773#msg2239773)

And this reply as well. (https://bitcointalk.org/index.php?topic=212490.msg2269009#msg2269009)

Also this reply. (https://bitcointalk.org/index.php?topic=212490.msg2232842#msg2232842)

This reply as well. (https://bitcointalk.org/index.php?topic=212490.msg2253578#msg2253578)

More on colored coin issuers. (https://bitcointalk.org/index.php?topic=212490.msg2326357#msg2326357)

Are colored coins impacted by the minimum transfer requirement? (https://bitcointalk.org/index.php?topic=212490.msg2353892#msg2353892)

Also a discussion on credentials and the distribution of risk. (https://bitcointalk.org/index.php?topic=212490.msg2316573#msg2316573)

Also: The Holy Grail in 7 Easy Steps. (https://bitcointalk.org/index.php?topic=212490.msg2324287#msg2324287)

------------------------------------------------------------------


I suggest people take "bluemeanie1" (aka Joshua Zeidner) with a grain of salt. (https://bitcointalk.org/index.php?topic=212841.msg2282547#msg2282547)

------------------------------------------------------------------

HAND HOLDING

People asked for some hand-holding on compiling OT:  Hand-holding. (https://bitcointalk.org/index.php?topic=212490.msg2232971#msg2232971)

------------------------------------------------------------------

People asked about donations to the OT project. (Currently I am using those to pay the Holy Grail Bounty (https://bitcointalk.org/index.php?topic=225954.0).)

The address is: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ

------------------------------------------------------------------

Answering questions about getting funds in/out of the legacy banking system...

Answer 1. (https://bitcointalk.org/index.php?topic=212490.msg2251931#msg2251931)

Answer 2. (https://bitcointalk.org/index.php?topic=212490.msg2272677#msg2272677)

------------------------------------------------------------------

VOTING POOLS

Answer about the voting pools. (https://bitcointalk.org/index.php?topic=212490.msg2253433#msg2253433)

Another answer. (https://bitcointalk.org/index.php?topic=212490.msg2253746#msg2253746)

This one also. (https://bitcointalk.org/index.php?topic=212490.msg2253948#msg2253948)

More on this. (https://bitcointalk.org/index.php?topic=212490.msg2327076#msg2327076)

Even more. (https://bitcointalk.org/index.php?topic=212490.msg2327199#msg2327199)

Distribution of risk across multiple pools. (https://bitcointalk.org/index.php?topic=212490.msg2327288#msg2327288)

------------------------------------------------------------------

Alright that's it, thank you all for your excellent questions! Now let's build this thing!

Not meaning to necro, but just wanted to make sure everyone got the latest update on this project.

I've just recorded some new videos showing the desktop client in action.

----------------------------------------------------------

INTRO:  http://goo.gl/Ea6rzq (http://goo.gl/Ea6rzq)

Send/receive payment, invoicing, untraceable cash, namecoin integration, end-to-end encrypted messaging, etc.

----------------------------------------------------------

ADVANCED:   http://goo.gl/i0J3AF (http://goo.gl/i0J3AF)

Market trading, decentralized bazaar, virtual corporations, smart contracts, legacy banking integration, etc.

----------------------------------------------------------

Also, the videos reference a couple of articles. Here are the links to those articles:


Voting Pools: How to Stop the Plague of Bitcoin Heists, Thefts, Hacks, Scams, and Losses

http://bitcoinism.blogspot.com/2013/12/voting-pools-how-to-stop-plague-of.html (http://bitcoinism.blogspot.com/2013/12/voting-pools-how-to-stop-plague-of.html)


Lex Cryptographia

http://bitcoinism.blogspot.com/2013/12/lex-cryptographia.html (http://bitcoinism.blogspot.com/2013/12/lex-cryptographia.html)

Thank you for your work. I think I will be trying to build an exchange using Open Transactions.

Wow. Just wow. Watching this space intently.

I just got goosebumps. This has the potential to be epic.

Thanks for the update videos..  Impressed with the progress on this and inspired by what it means for all!

Just wait until Moneychanger gains the ability to also act as a Bitcoin wallet too, transparently.

Incredible.

I cannot wait to see this finally running full-steam.

Wish I'd noticed it when it first appeared in May.

I'm working hard on the bitcoin implementation right now, can't wait to see it in action either :)

Fantastic !

Thanks for presenting Pandora's box  ;D

fellowtraveler,

I see you're speaking at the Miami conference in a couple of weeks. Will you be discussing the technical details of OT during your talk? If not, would you consider a mini breakout session?

I suppose I could do a breakout session. I'll be walking around for a few days answering questions anyway I'm sure.

I suggest also checking out the wiki, the videos, etc.

I can't wait to see what the near future holds for Moneychanger, and looking forward to your talk at the Austin Bitcoin Conference.

Amazing!
Is it already possible to build (at least beta version) of a public exchange, where actual exchanges can be performed, based on this?

short answer is yes.

... but be aware the learning curve for the backend server config/set-up is steep.

Just a big WOW. This is something really incredible you are working on. Keep us updated!
Does seem a bit complicated, but surely things will be made a bit more easy for the average user.

Any issues with the app on IOS (being that it integrates payments) or do you see Apple giving in here?

and be a color-coin enabled wallet....

Can you please explain the deposit part of the system, how and where to a user deposits money? Or the company running the server should handle this part?

Holy shit balls, how did I miss this?

Sort of how Black Swans work.
I did see BTC at cents, but how did I miss getting in then?  ;D

OT doesn't work that way. It doesn't handle money - just obligations.

Another way to think of it is that OT handles liabilities, not assets.

For example, if you are running a Bitcoin wallet on your own computer (Bitcoin-Qt, Multibit, Armory, etc) and you have a balance, there is no counterparty risk associated with them: that balance represents an asset you control.

If you deposit your bitcoins on Mt Gox then you don't have bitcoins any more, you have a promise from Mt Gox to allow you to redeem a balance in their system for bitcoins - your balance on Mt Gox is their liability.

So, if you've got a system that creates liabilities, then OT is superior way to track these liabilities compared to the alternatives. Returning to the previous example, Mt Gox doesn't use anything more complicated than a MySQL table to track its liabilities. They don't give you cryptographically secure receipts, and if they choose to alter your balance (via a simple database command) there's nothing you could do about it. You can't even really prove that they owe you any bitcoins at all, at least for reasonable definitions of "prove".

Mt Gox isn't special in this way - all existing Bitcoin websites work pretty much the same way.

Your original question is backwards then. OT should be used where third parties are already depositing funds in order to add better security and functionality to the situation.

I just want to understand, if I setup OT server, can it handle MTGox like operation, where there is no actual website for exchange, but OT server with end users using software from their computers... for the simplicity, lets say the service would offer only BTC/USD exchange service on the beginning and lets say we offer an option to actually deposit money the very same way as mtGox (wire transfer etc), is it possible to create such a virtual exchange with deposit option? The thing is that the average Joe needs it to be as simple as possible and the very first thing he needs an ability to have those "assets" in his own wallet, in our case $USD for the beginning... to start rolling...

If you're operating a service that accepts customer deposits, then you can issue OT receipts for those deposits instead of just making database entries in your own system. You technically don't actually need to run your own server for that - you can theoretically use any OT server.

The advantages of doing this from the perspective of your customers is that it means that you won't have the ability to arbitrarily change their balance, they will will have cryptographic proof of how much you owe them, and they can trade their balances like currency.

The disadvantages are that the customers will need to install Moneychanger (or some other suitable OT client) to use your service and Moneychanger isn't finished yet. Also the features that OT receipts provide which your customers will like probably aren't legal to give them when you're issuing receipts for USD.

Meaning you'd need money transmitter licensing for every State (in which you have customers)?

Only for US-based customers ... the servers can be operated in any jurisdiction at all, or in the cloud with multiple parallel instances making it impossible to know which server is performing the notary function. The issuers could also be based in any jurisdiction, or perhaps even as pseudoonymous entity operating on anonymous network like Tor, I2P, Freenet, etc.

Thank you for the explanation, now it is much clearer.
Ok, the issue with receipt is not a problem as far as we aren't talking about USA, even more, if not operated anonymously, it can be operated under certain bank/exchange license, I already have some legal solution...
Now another question. Is it possible to use OT server as a core server (through API?) with mtGox like interface for customers, until moneychanger is realeased or just for those customers who don't want to download it?

You'd have to write all that code yourself, AFAIK.

Of course, just need to know that this possible...

There are also some example simple web client wallet projects ... but nothing fully polished yet.

e.g.
https://github.com/stretch/otweb (https://github.com/stretch/otweb)

well done fellow traveler!
i am amazed by your work!
this is the future!!!

Wow, how did I miss this?!

Still trying to understand properly it but I think I get the gist. Exciting stuff.

Is there an estimate when moneychanger will be released to the masses?

Not really, it is dependent upon volunteers and bounty donations ... and to be honest help is pretty thin on the ground with so much money hovering up talent in the crypto space, there are not that many free agents left out there ... for coding, building, packaging, testing ....

that means that there should be something allowing to commercialize the product, in certain way... so it can be pushed... What about having a small commission in moneychanger? For example, if commission can be set in moneychanger to work on certain (commercial) OT server, than those who would like to run this commercial OT server might be interested to invest into faster development? Am I missing something?

Good point...

Am I correct in understanding that MC is dependent on OT? If so is OT ready for prime time, can anyone set up an OT server?  Where would one start if they wanted to try? What sort of hardware would be required?

Newbie questions, I know, but I need to start somewhere.  :-[  How does a newbie like myself make a positive contribution, or do I just sit and wait.

BTW, I'm nobody's Grandmother, but I am a Grandfather. I would be more than happy to be a usability guinea pig, should someone need one.  ;)

I will probably never say that OT is "ready for prime time" since, working in crypto-systems, I am extremely conservative and paranoid.

We've done a lot of testing over the past four years, but I want to do more. We've done some static/dynamic analysis, but I want to do more. We've had the code open-source for years, but I still want to pay experts to audit the code. Monetas is starting on some QA but that will be an ongoing process.

We are just now getting to the point where the Desktop app is usable, and even then we need install programs before normal users can access it. (I've been testing an install of the Mac version, but don't have an install ready yet for Windows/Linux.)

If you want to start playing with it, there's a bit of a learning curve on the server side. The first thing I would do is get a Mac or Linux system and then build OT on it:
http://github.com/Open-Transactions/Open-Transactions

Once you have it built, I would copy the sample data over:

mkdir ~/.ot
cp -R Open-Transactions/sample-data/ot-sample-data/* ~/.ot

Then you can start the server: otserver

Then you can use the command-line client. You can also use the desktop client if you want to build it:
http://github.com/Open-Transactions/Moneychanger

I have a Mac install of that desktop client, and some testers have access to it, though we will make it more accessible to others soon. We still need to make install programs for Windows/Linux but it shouldn't be too hard.

Once you are comfortable using OT with the sample data, the next step would be to create your own server contract. To get started doing that, just erase the sample data and run otserver with no data. It should walk you through the process of setting up your own server (it's no picnic.)

Here is Chris Odom aka Fellow Traveler, speaking at Miami Bitcoin conference, some people may find it useful. Enjoy!

Thanks to "Let's Talk Bitcoin!" for great audio.
 
https://soundcloud.com/mindtomatter/miami-2014-chris-odom-on-1?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+TheDailyBitcoinShow+%28Let%27s+Talk+Bitcoin%21%29

Thanks. Are the slides he was using available anywhere?

http://ciyam.org/open/?cmd=view&data=20130606055250338000&ident=M100V137&chksum=a2a9d6d5

It appears that all the funds have been removed and *nothing has happened with this project for months*.

So unless I am led to believe otherwise then I will be closing it off at the end of this week.

Actually this project has been worked on continually, even up until today, as you can see in the commit history:

https://github.com/Open-Transactions/Moneychanger/commits/develop

We have a lot of new features added, and an announcement is overdue. For example, Namecoin and Bitmessage have been integrated. I've been in the middle of a move to Switzerland, and busy with the Bitmessage integration, so I want to get that tested up and make a new video before I post a big update here to this thread.

As for the funds, they are still all there, I just moved them to a separate address out of concern for security. The amount was sitting on my desktop and was making me nervous, so I moved it to a paper wallet.

Pls just leave the project on CIYAM for now, and soon I will get in there and update the CIYAM page. Lots of the sub-bounties can be closed and paid out, and I will slip in new addresses for the bounties that remain, so the funds can be visible again. Lots of progress going on lately!

Okay - glad to know things are still progressing fine (just a pity we haven't been able to follow the progress through CIYAM Open).

I will keep the project active.

I am following the project on Github, Fellowtraveler and several others are active. I see multiple submissions every single day or at-least a week to the OT Project. Best way I know you can follow the developments of this project.

BitMessage is anonymous but NOT secure. Add a layer of crypto to your messages and you may have a chance.

It's just starting level of tech that can be improved upon by others. If i understand it correctly, it's wonderful thing that can go really long way in the future and opens up bunch of possibilities.

if you crypto all your messages it defeats the whole concept of immortality.  see.  if you encrypt the word of G-d.  things get funny.  like people going to jails for weed.. :(

Can you elaborate?

Pretty cool. What future plans do you have with it?
A dedicated 'instance' as a tor hidden service would force anonymous readers too. The ability to publicly respond (through bitmessage) would be interesting too (or at least link-backs)

glad to know things are still progressing fine (just a pity we haven't been able to follow the progress through CIYAM Open).

I will keep the project active.

Here I am brought into this all under the idea that everything I do can be foxy..  Do you see me?

bitmessage is just another shining example of what can be accomplished with blockchain technology. Bitcoin itself was just the tip of the iceberg.

Very interesting. Good to know!

Bitmessage is dead (https://bitmessage.org/forum/index.php?topic=4136.0).

Damn. That's sad  :'(

I've only skimmed the linked thread, but I thought BM had a sharding mechanism of some sort (streams? channels?) to prevent this problem. Why isn't that enough to solve this problem?

It is. (once it's actually implemented)

Someone's just FUDing.

If you actually READ (as in RTFM) the thread, such a grouping or streams solution is not simple as you might naively assume. And probably why it is not implemented.

http://4.bp.blogspot.com/-hG__keR9Nn0/UYGXHQZG2iI/AAAAAAAABMw/C2ZtkrLWqD0/s1600/rtfm_finished.png

Anyone who is actually a programmer knows the "devil is in the details". So these idiots who make proclamations based on some general rumor or conceptual idea, can't hold a candle to someone who is actually down in the trenches implementing this stuff and thus speaks from a deeper understanding of the issues involved.

For the meantime, Bitmessage is dead. And bringing it back to life isn't going to be trivial.

So who is trolling, as you always do.

Anyone still paying attention to this "Legendary" idiot deserves the misinformation he spews.

For someone who's only been around for two weeks, you have remarkably strong opinions about what's going on.

Your nemesis AnonyMint wasn't around for 2 weeks.

I have been playing around with Bitmessage.  It looks like it doesn't work well.  Messages I sent out a few days ago still aren't received.  Didn't have much important to say, but still it kind of sucks. 

I was noticing from what I read, Bitmessage is relying on PoW.  And right now just one spammer with probably just a few computers is bringing it down.  I am sad to imagine what an Asic built just to take down Bitmessage could do, if that is even possible. 

Seems to still work for me. Also, probably won't be an issue for this specific project, since OpenTransactions can have its own bitmessage stream separate from the rest of BitMessage (like a separate fork of bitcoin)

So ~1.5 years later... what exactly is still missing that OpenTransactions can finally take off?

I have download the bitmessage right now.it's cool!

So what do the Snr's and legends think is going to come of this (https://www.indiegogo.com/projects/pep-pretty-easy-privacy) tech

In my experience bit message has been somewhat buggy.

Isn't Bitmessage incorporated into Open Bazaar?

Why dont they add decentralized chat in the bitcoin wallet?

If you look at some of the videos on OpenTransactions, FellowT mentions that different encryption methods can be used for messaging and Bitmessage is one being used, at least that is my understanding, so is this thread a discussion solely about Bitmessage and its future, or its use within OT? Its a thread that was started in May 2013, and a lot has happened since.

Pretty much everything about OpenBazaar is a carbon copy of OpenTransaction, One Works through browser, the other a desktop client

Looks like just an encryption layer on top of existing centralized-server based communication mediums. BitMessage aimed to replace the actual communications channel with a decentralized peer-to-peer model, not just add encryption.



I think this thread is mainly about OpenTransactions. Also, OT and OpenBazaar are very different from what I have seen so far. Sure, maybe you could make OpenTransactions do everything OpenBazaar does, but you would have to change a lot of the code and write a lot of your own, since one is specifically designed to issue digital tokens and trade them around, and the other is specifically made to market and sell physical products.

Because it would make to much sense.  ;)

No, because decentralize everything means decentralize everything. We don't want to lump everything together, because it would make the Blockchain bloated, bitcoin wallets cumbersome, and lock us to a single main way of communicating, instead of being able to experiment with new ideas on the site, such as with BitMessage.

Fair enough, and I am not here to compare either. I believe there is more to OT than you say, and its Bazaar feature is what I am talking about, which is to market and sell physical products. Using multisig and bitmessage.

Just noticed there is some activity in this thread, so I wanted to answer these questions...


Open-Transactions itself is fully-functional.

What's still missing is the voting pools (using multi-sig to prevent the OT server from stealing any Bitcoins transacted there.)

However, Monetas is hard at work building the voting pools...
You can read updates on the Monetas blog: http://monetas.net/blog/ (http://monetas.net/blog/)

Design info for voting pools has started popping up on the OT wiki: http://opentransactions.org/wiki/index.php/Voting_Pool_Deposit_Process (http://opentransactions.org/wiki/index.php/Voting_Pool_Deposit_Process)

Once voting pools are ready, it should "take off," as you say. It will take a few more months.


Here's the latest video update: https://www.youtube.com/watch?v=uJKWDC4q5rA (https://www.youtube.com/watch?v=uJKWDC4q5rA)

As you can see from the video, we are agnostic to the exact transport method, with Bitmessage being only the first integration.

However, Bitmessage is now fully-integrated and working in the Moneychanger desktop client! (As of the past couple months, as shown in the video.)

Now that we have Bitmessage integrated, we can start adding the features described in this thread, such as cross-server discovery for trading, legacy bank integration, etc. (And of course, the Bazaar feature.)


To be clear: Bitmessage is not integrated into OT itself. Rather, it's integrated in the Moneychanger desktop client.

Similarly, the Bazaar will not be built into OT itself. Rather, it's now being built into the Moneychanger desktop client. Here is some of the design info: http://opentransactions.org/forum/index.php?topic=3821.0 (http://opentransactions.org/forum/index.php?topic=3821.0)

The basic concept is to have decentralized markets for goods and services, sort of like e-Bay, except without the server. Like a P2P version of e-Bay.

To whatever degree we have inspired any other projects, that's great! Let's change the world.

Official version of Bitmessage is functioning for me again, even though the broadcast spam is still high.

Apparently many users moved to the new experimental version.

Any plans for a release 1.0 ?

I said I'd collect my bounty when 1.0 is released, but that was very long time ago.

Would be nice if I can get the bounty paid out to this address within the next days:
1VhNZaUAxQXxbRFuxtL8ZoqE6WnJ4Bpqu

If anything needs additional fix please let me know.

Hmmm, that reminds me of all that library work done on Moneychanger ...