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

[fellowtraveler]

Re: bluemeanie1

As long as you are posting in my threads, I think it's important that people know your true motives.

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.

[mmeijeri]

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

[fellowtraveler]

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.

[bluemeanie1]

Re: bluemeanie1

As long as you are posting in my threads, I think it's important that people know your true motives.

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.

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

[fellowtraveler]

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.

[fellowtraveler]

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.

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.

[mmeijeri]

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?

[fellowtraveler]

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.

[mmeijeri]

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.

[fellowtraveler]

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!

[2weiX]

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.

[mmeijeri]

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

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.

[fellowtraveler]

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

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

[mmeijeri]

What happens if the server fails to sign?

[fellowtraveler]

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. Kudos to Zooko!

[mmeijeri]

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.

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

[fellowtraveler]

So what information does the recovery request contain,

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

what information do the pool members have to verify the situation?

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

[mmeijeri]

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

[lunarboy]

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.

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?

[DiB]

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.