Here's how we plan to do it in Open-Transactions: Let's say that 10 transaction servers voluntarily choose to form a voting pool (to provide more security for their users.)

This means that all bailments of BTC into the pool are sent to a list of 10 addresses -- the 10 servers in the pool.

Any bailments back out of the pool will require a (say) 8-out-of-10 vote of those servers to get the coins back out.

The servers simply look at the bailment request, verify the signatures on it, and then vote. Most of the time (if the signatures verify) then there will be 10 "yes" votes. If the signatures don't verify, then normally you will get 10 "no" votes.

So for that pool, I wouldn't expect any new voters to ever be involved, other than the 10 servers participating in that pool.

Of course there will be multiple pools, and users will have to choose which pools they trust. It's not IMPOSSIBLE to hack the funds, but it would require hacking 8 servers instead of 1. Since everyone here uses stuff like MyBitcoin and MtGox (which would require only hacking a single server) then my proposal is a significant improvement on the current state of things.

I don't think you really understand how voting pools / multi-sig works.

If any jackass can just go and add voters to any multi-sig transaction they want, then the whole concept of multi-sig becomes worthless.

So then why do you think they added it to the BTC protocol in the first place?

I'm hoping this change won't impact colored coins -- because colored coins are important.

Can anyone comment on this?

Bitcoin doesn't solve the trust problem either, since 51% of the hashing power can forge transactions.

A voting pool would be composed of a group of transaction servers, such that X-out-of-Y of the servers would have to vote to get coins back out of the pool.

For example, if there are 20 servers in the pool, and the multi-sig requires 15 votes to move the coins, then you would have to hack 15 of those servers, not just one, to get the coins out of the pool.

It's not as secure as the blockchain itself, but it's certainly a lot more secure than having to trust a single server -- which is mostly what the whole BTC community does with these servers like MtGox and MyBitcoin.

I would be happy to sit you down and train you on it.

What city do you live in?

Or we can meet on IRC.

Yes.

Kudos for someone42 for this post. This is exactly what I was coming onto this thread to write.

Especially the part where he says, "[then] a light flashes on the BitSafe and "Send 1.815 BTC to www.bitmit.net?" appears on the OLED display."

This is exactly what I need for Open-Transactions.

We have now gotten OT to where it installs on 64bit Linux through apt-get (using custom repo).

What do I need to make happen, in order to test OT on your device? Is there any comparable hardware I can buy now at home, which I can use to simulate running OT on your device? (So I can prepare OT to run on your device...)

This project is very interesting and important, especially the open-source aspect of it. May I recommend also that you choose an open-source license with patent protections built in so that your work doesn't later become subject to patent trolling. That will impact companies who try to use your hardware designs.

I am available fellowtraveler@rayservers.net for any discussion. Great work!

FYI, OT is already capable of instant secure payments, and dispute mediation (see escrow smart contract.)

What OT is missing, is "secure handling of users' funds." That is, you would still have to trust the OT issuer who is holding your physical BTC.

The solution for this is to store the BTC in a voting pool (M-of-N) on the blockchain itself.

As you proceed with BitContracts.org, may I ask that your first action be the implementation of a couple of simple C functions for M-of-N blockchain transactions. I know that my own project will start using it right away.

My own proposed solution is, when BTC are bailed onto a server, instead of giving the coins directly to the server (and risking that the server will steal them, or get hacked)...

...instead of giving the coins directly to the server, you put them into a voting pool composed of say, 50 or 100 servers, where you need X-out-of-Y vote from the other servers, to bail coins back out of the pool. Note: You don't need to do this for every single transaction, since OT transactions occur off-chain. Instead, you just need to do this when moving actual BTC in or out of the pool.

The technical details are described more in-depth here: http://bitcoin.stackexchange.com/a/834/309

This is not just an OT solution -- everyone should be doing this. All those server heists, where they lost hundreds of thousands? Those never needed to happen. Use voting pools use voting pools use voting pools stop getting fucked.

It's me again, your buddy Fellow Traveler...

In the 2 months since my last announcement, RADICAL progress has ensued on
the Open-Transactions project.

As our number of contributors has continued to grow, so also our progress
has accelerated!

Let's get right to it...

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


1. "OT MADE EASY" -- NOW IN ALL LANGUAGES !
2. IPHONE SUPPORT
3. LINUX TARBALL
4. OTCRYPTO IS FINALLY COMPLETE
5. CREDENTIALS  !!   <==== Big update.


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


In brief…


1. "OT MADE EASY"  -- Transactions with a single line of code via the
ultra-high-level API, now available in ALL languages, with new sample
scripts in Python, PHP, CSharp.

2. IPHONE SUPPORT -- New iPhone build setup + skeleton project now
available!

3. LINUX TARBALL -- Install OT on Linux, with dependencies, via a SINGLE
COMMAND!

4. OTCRYPTO IS COMPLETE -- The OTCrypto abstraction is now complete.

5. CREDENTIALS  !!  -- Major update, enabling identities from CAs and
blockchains.


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


In detail...



1. "OT MADE EASY" NOW AVAILABLE IN ALL LANGUAGES


OTMadeEasy, the ultra-high-level API, is now available in ALL languages
supported by OT.

Transactions are now officially reduced to a single line of code, in all
languages.


Here are some sample scripts in CSharp, PHP, and Python:

https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/tests/csharp/Main.cs<https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/tests/csharp>
https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/tests/php/php_ot_test.php<https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/tests/php>
https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/tests/python/python_ot_test.py<https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/tests/python>

Each of the above scripts demonstrates a few API calls, including a CASH
WITHDRAWAL transaction.
(More sample scripts coming soon.)

*Thanks to contributor BlueWall for the CSharp script.
*(Bluewall is working on an OT integration with OpenSim.)

Here's an article on using the API:
https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

Here is complete working sample code for every possible use case of OT,
using the high-level API:
https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot


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


2. IPHONE SUPPORT


Thanks to contributor Happywarrior, OT now builds for iOS, and also
supports the iOS keyring.

iOS build setup and skeleton project! (For iPhone / iPad development.)
https://github.com/happywarrior/OTClient-iOS


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


4. LINUX TARBALL


Thanks to contributor randy-waterhouse, we now have a Linux tarball for OT,
meaning it's possible now to install OT on Linux, with dependencies, via a
single command!

https://github.com/randy-waterhouse/opentxs


We still need to get the repository hosted, but here's the command that
will install OT, once the tarball is hosted:
   sudo add-apt-repository ppa:ppa-name ; sudo apt-get opentxs


Note:  repository ppa:ppa-name doesn't exist, it is just an example.
(Anyone interested in hosting it?)


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


5. OTCRYPTO FINALLY FINISHED


The OTCrypto abstraction is now complete. What does this mean?

1. It means the entire OT crypto code is now localized to a single class:
OTCrypto. (All the rest of the code just uses OTCrypto.) This will make it
easy for code audits of the crypto portions. Any volunteers to do the first
crypto audit on OT? Don't all jump at once.

2. It also means that we actually could replace OpenSSL with GPG, or with
any other crypto library. All you'd have to do is make a copy of the
OTCrypto_OpenSSL class named OTCrypto_GPG, and then just use GPG calls for
the method internals, instead of the OpenSSL calls that are there now.

===> Voila! OT using GPG instead of OpenSSL. Any volunteers?


The OTCrypto interface now has fully-implemented methods for:

-- randomizing memory,  (entropy callback coming soon.)
-- calculating digests,
-- converting to-and-from base62
-- and base64,
-- key derivation,
-- secret-key encryption and decryption,
-- public-key encryption and decryption (in RSA envelopes with multiple
recipients),
-- ...and digital signatures and verification.

OT uses this interface exclusively for all its crypto--and technically you
could, too. My goal has always been to make crypto as accessible as
possible to other developers.


BUT WAIT, THERE'S MORE!

We *also* finished abstracting out OTMint and OTToken, where the
UNTRACEABLE DIGITAL CASH is currently implemented using Ben Laurie's
"Lucre" library.

So for example, if you wanted to remove Lucre (which uses OpenSSL) and
REPLACE it with the PGP "Magic Money" digital cash implementation by
Pr0duct Cypher, simply make a copy of the OTMint_Lucre and OTToken_Lucre
classes, name the copies OTMint_MM and OTToken_MM, and then fix their
internals to call the Magic Money library calls instead of the Lucre
library calls.

Voila! OT is officially modular enough to work with ANY chaumian cash
algorithm!

===> This also provides a very useful testbed for researchers who would
like to test their own digital cash algorithms inside a fully-operational
transaction system.


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


3. CREDENTIALS


  -- We've coded a major change in OTPseudonym, to enable identities that
could be anchored via one of many different sources, such as: Certificate
Authorities, blockchains, URLs, etc.

From the very beginning, OT has managed identity in a very simple way: The
NymID is a hash of the Nym's public key, and any messages must be signed by
the corresponding private key.

Though OT will continue to support these "public key-based" Nyms, other
options became necessary for various "real world" projects, and these new
options have now been added via the OTCredential class.

HOW DOES IT ALL WORK NOW?  Two important concepts have been incorporated
into the OT identity system, in order to "embrace and extend" all other
possible identity systems.

1. Source string.
2. Master credentials and subcredentials.

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

1. Source string.


The NymID is now calculated as a hash of the Nym's source string. In the
case of "public key-based" Nyms (classic style OT) the source string
remains the public key itself. You hash it to get the ID, as before.

-- But now, alternately, the source string could instead be the unique DN
info for a traditional CA-issued Cert.
-- Or, the source string could be a URL…such as a Namecoin address.
-- Or, the source string could instead be a Bitcoin address.
--- Etc.  (Many sources are possible, and they all have different
properties.)

In all cases, a Nym's credentials must verify through their OWN SOURCE.

For example, if the Nym's source string is based on the unique DN info for
a CA-issued cert, then the Nym's master credential must be signed by a Cert
with that same DN info, AND the cert must verify through its own CA.

-- Or, if the Nym is based on a Namecoin address, then the Nym's master
credential ID should be verifiable through that Namecoin address.
-- Or if the Nym is based on a URL, then the Nym's master credential ID
should be posted at that URL.
-- Etc.  Makes sense?

As long as a Nym verifies through its own source, and as long as the source
hashes to form the NymID, then we are able to have MANY credentials, and
MANY potential types of sources, for our Nyms…

…and these sources all have different properties! For example:

-- A CA-issued Cert, unlike a plain-jane public key, can be controlled by a
central authority. This means, for example, if a commercial venture wishes
to revoke the Cert for a specific Nym, and replace it with a new Cert
controlling that SAME Nym (perhaps while simultaneously replacing the
former employee who originally controlled that Nym, with some new employee)
then this can now be done, AND while keeping the Nym's ID unchanged.

-- Alternately, for those who distrust CAs, credential IDs posted to a
blockchain will have full censorship-resistance for their digital identity,
yet still be publicly revokable. See this project, for example:
https://github.com/bcpki/bitcoin/blob/master/README.md

"The BCPKI-project (blockchain-PKI) establishes the blockchain as a root
CA."


My own commercial effort needed this "source" stuff in OT, so we went ahead
and added it for the rest of you, too! Speaking of which, please direct all
business inquiries to Johann@monetas.net and all technical inquiries to
myself  :-)


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


The second piece of the new OT identity code:


2. Master credentials and subcredentials (for a single NymID.)


OT itself now supports its own built-in master credentials which can issue,
sign, and revoke sub-credentials.

Each credential now contains THREE KEY PAIRS: A signing key, authentication
key, and encryption key.

You can create multiple master credentials per Nym, and multiple
sub-credentials per master. The NymID will remain unchanged throughout.

Eventually the idea is to also add sub-credentials for other authentication
methods, such as third-party services, 2-factor auth, etc.

===> This new system will make that easy to do :-)



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


IN OTHER NEWS...

Don't forget, we now have a bash test script, which performs a
halfway-comprehensive set of unit tests via the command-line tool. (Great
for development…)
https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/tests/bash/ot_test

We now run all our new code through these tests before any releases.


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


NEW OPENTXS (command line) COMMAND:  "showincoming"


"opentxs showincoming" shows all incoming transfers, payments, invoices,
receipts, etc.

Next, try commands such as:  acceptall, acceptmoney, acceptreceipts, etc.

I also recommend:  sendcheque, sendcash.

You can get a lot of mileage out of the command-line tool now, in only a
few short commands.

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

As always, commit history:

https://github.com/FellowTraveler/Open-Transactions/commits/master


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

Windows developers:  It will be a day or two before the latest version
builds again on Windows, so we suggest you wait a couple days before
grabbing the latest version.

That's it for now, more coming soon!

Until next time,

-Fellow Traveler
https://github.com/FellowTraveler/Open-Transactions/wiki

• Alice walks into a coin shop in America, and gives them a gold coin.
• The coin shop in America sends some Bitcoin to a coin shop in Britain.
• Bob walks into the coin shop in Britain and picks up the gold coin.

Therefore you can use Bitcoin for sending gold. (Or any other form of value.)

This is a similar mechanism to Silk Road, eh? You can use Bitcoin for sending Drugs.

You can use Bitcoin for sending anything.

Goldbugs will learn to love Bitcoin when they realize they can use it for sending gold.

Goldbugs will learn to appreciate Bitcoin when they learn that they can use Bitcoin for sending gold.

It's not good to owe a debt.

If you have a creditor, that creditor has some license to cause damage.

For example, if he smashes your car windows, you can sue him for damages, but he would countersue for his own damages (the debt you owe him) and eventually any damage he does to you would just be offset in court against whatever you already owed him.

Methinks the lady doth protest too much.

You still haven't figured it out?

http://www.weidai.com/bmoney.txt

What is this "money laundering" crime of which you speak?

I can find nothing about it in the Law of Moses.

Each new receipt, you must sign the new balance.

So if you have a 0 balance, and then you receive 50 sheep, you sign a receipt that says, "My balance is 0. I'm receiving 50 sheep. My new balance will be 50."

Then let's say you receive another 50 sheep: "My balance is 50 sheep. I'm receiving 50 more sheep. My new balance will be 100."

Then let's say you send 50 sheep to Bob:  "My balance is 100 sheep. Please send 50 sheep to Bob. My new balance will be 50."


See? You must sign the balance on each new request. Therefore the most recent receipt shows the current balance, with your signature on it (and the server's signature.)

Therefore in any dispute, the winner is the one with the newest receipt.

If an issuer issues sheep onto servers A, B and C, then the "sheep" currency is now available on three servers.

If you redeem a cheque that was drawn from an account on server A, then your wallet will naturally redeem it at server A,
just the same as a web browser trying to display an image from webserver A, would download that image from webserver A.
(In both cases, the client software just accesses the appropriate server based on what's in the URL.)

There are several ways to move your "sheep" from Server A to Server B:

1. Anyone who has a "sheep" account on both servers, can perform this transfer for you.

2. Including, obviously, the issuer himself. He can take sheep from you on Server A, and give you sheep on Server B.
   (In fact, anyone with accounts on both servers can do this.)

3. You could sell the Sheep on the exchange in return for Bitcoins. Then withdraw the Bitcoins from the server directly, and move them onto server B, where you use the BTC to purchase Sheep again.

4. A protocol could be devised between servers that allows them to open accounts with each other, and thus perform "wire transfers" on behalf of their users.



This is not correct. The whole idea with OT is that the user stores his last signed receipt, and is thus able to prove his balance, as well as which instruments are valid, simply via that last signed receipt. In other words, the receipt is the account, and both parties have a copy of it.


Remember that the OT server cannot change balances or forge receipts. (Your signed request appears on every server-signed receipt. So the server cannot forge a receipt because it cannot forge your signature, because it does not have your private key.)

And as long as the issuer has an auditing protocol in place that meets his standards, then the server cannot commit inflation either.

Therefore, whether there are 100 servers, or 1000 servers, they cannot defraud the issuers or users.


Thanks for the opportunity  :-)