Author

Topic: Open-Transactions / Moneychanger (latest release: v0.87e) (Read 5241 times)

legendary
Activity: 1708
Merit: 1020

Vote Moneychanger as your favorite Bitcoin Project of Autumn 2013
sr. member
Activity: 440
Merit: 251
Now that flattr accepting funding through bitcoin have you thought of setting up a flattr profile for the project.  So that the project can receive regular funding.  I'd be happy to set up a subscription.

Great idea, I will get one set up ASAP and post the link to our wiki opentransactions.org
legendary
Activity: 1372
Merit: 1003
Now that flattr accepting funding through bitcoin have you thought of setting up a flattr profile for the project.  So that the project can receive regular funding.  I'd be happy to set up a subscription.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
this wont work on Ubuntu Lucid:

Code:
checking for PKGS... configure: error: in `/home/k1773r/git/Open-Transactions':
configure: error: The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

pkg-config is working therefore clearly not my fault.

i tryd this now twice, still dosnt work (following compiling guides).

Probably your pkg-config version is too old (as the error says). The docs assume ubuntu 11.04 (natty) or later I think.

NB: as quick hack try changing the line in configure.ac to your version of pkg-config (no promises it will work)

Code:
$ pkg-config --version

and in /home/k1773r/git/Open-Transactions/configure.ac

Code:
PKG_PROG_PKG_CONFIG([YOUR-VERSION-HERE])

and do the $autoreconf and etc ...
legendary
Activity: 1792
Merit: 1008
/dev/null
this wont work on Ubuntu Lucid:

Code:
checking for PKGS... configure: error: in `/home/k1773r/git/Open-Transactions':
configure: error: The pkg-config script could not be found or is too old.  Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.

pkg-config is working therefore clearly not my fault.

i tryd this now twice, still dosnt work (following compiling guides).
legendary
Activity: 1222
Merit: 1016
Live and Let Live
sr. member
Activity: 323
Merit: 251
I'm not sure about the specific application you propose (I'm too hopped up on cold medicine to wrap my head around it tonight).

But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.

This is exactly what Open-Transactions does, I believe.

When it's said that the issuer must be trusted, we're talking economically not cryptographically. In Open-Transactions, nobody--not the server operator, not the issuer, not anybody but you--may change account balances or token ownership. That's a cryptographic guarantee. However since the issuer is allowed to generate at will and without cost as many new tokens as they want, for existing tokens to have any value you have to trust that the issuer will live up to their contractual promises (backing, redemption, etc.). But that's a separate issue from existing account balances/token ownership which is protected from tampering.
And that's what I want to eliminate (or rather reduce). Rather than having the issuer storing the Bitcoins backing the tokens, the bitcoins are stored within the tokens (in an unaccessible encrypted form), so that an issuers responsibility is reduced to decrypt a coin when given a valid token.

The difference in trust needed is similar to the amount of trust needed in a regular webwallet vs a client-side java-script web-wallet like blockchain.info. The issuer can only steal your coins at the exact time you hand them the token to decrypt it, which means they can only get away with a fraction of the value.
newbie
Activity: 4
Merit: 0
comment:

After make install'ing Open Transaction,
you have to run "ldconfig"
legendary
Activity: 905
Merit: 1012
I'm not sure about the specific application you propose (I'm too hopped up on cold medicine to wrap my head around it tonight).

But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.

This is exactly what Open-Transactions does, I believe.

When it's said that the issuer must be trusted, we're talking economically not cryptographically. In Open-Transactions, nobody--not the server operator, not the issuer, not anybody but you--may change account balances or token ownership. That's a cryptographic guarantee. However since the issuer is allowed to generate at will and without cost as many new tokens as they want, for existing tokens to have any value you have to trust that the issuer will live up to their contractual promises (backing, redemption, etc.). But that's a separate issue from existing account balances/token ownership which is protected from tampering.
sr. member
Activity: 323
Merit: 251
But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.

Well, if what you are suggesting can really be done it would be a giant leap forward. Such a mechanism has been sought for some time (OT tokens provably-backed by BTC from an incorruptible automated issuer that can be traded as digital cash) ... code it up and reap the kudos  Wink
Read the thread I linked to. I'm not entirely sure on what can and can't be done, and I may very well have misunderstood or missed something important.

As I understand it, what can be done according to that thread is this. An issuer could make some information public so that anyone could create bitcoin tokens for the issuer. So by using this public information I could create an encrypted private key that not even I can access (only said issuer could by using a passphrase he kept secret). I can also derive the corresponding bitcoin adress without decrypting the data and obviously fund said bitcoin adress. I could also proove to someone else that this token contains a private key for an adress with bitcoins in it (and who the issuer with the passphrase needed for decryption is).

If such tokens were traded using an OT-server, I believe the trust needed in issuers could be reduced dramatically. I may very well have missed something so someone with better math skills should check it out.
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo
But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.

Well, if what you are suggesting can really be done it would be a giant leap forward. Such a mechanism has been sought for some time (OT tokens provably-backed by BTC from an incorruptible automated issuer that can be traded as digital cash) ... code it up and reap the kudos  Wink
sr. member
Activity: 323
Merit: 251
But as far as I understand it, in the current implementation you need to trust the issuer. What I'm proposing would mean that not even the issuer has access to your coins. The issuer would be the only entity that can decrypt the bitcoin private key in the token. But they don't have acces to the tokens except when someone wants it redeemed.
legendary
Activity: 905
Merit: 1012
You can already do that. In Open-Transactions, issuers and the server are distinct entities.
sr. member
Activity: 323
Merit: 251
I love the work you guys are doing with Open-Transactions. Keep it up.

I have a potential idea in regards to bitcoin implementation. In BIP38 casascius describes a way in which someone can create and fund an encrypted key that not even they could use. I believe this could be used in order to remove some of the trust currently needed in issuers. Users (or an OT-server) should be able to create and fund their own anonymous cash tokens. Then they could exchange them freely using a OT-server and at no point could anyone run away with the money. Rather than keeping the coins, an issuers only job would be to decrypt them upon request and proof of ownership.

One weakness I see is that the issuer could try to take part in the economy and save copies of the cash tokens, spend them, then decrypt the private key and spend the actual bitcoins. But this would still require far less trust than what is currently needed, since the issuer could only steal coins from tokens they have had in their possession.

There are potentially more use-cases for this but digital cash was the first that entered my mind. Issuers not having access to coins is a big deal I think.

This is the thread with the BIP38 discussion.
https://bitcointalksearch.org/topic/bip-38-discussion-thread-passphrase-protected-private-key-format-129317
newbie
Activity: 4
Merit: 0
legendary
Activity: 3920
Merit: 2349
Eadem mutata resurgo

developers are usually on freenode IRC #opentransactions ... if you don't use a IRC client you can use (temporarily) webchat link

https://webchat.freenode.net/?channels=opentransactions&uio=d4

PS: it seems like you might be missing the msgpack development package (msgpack.hpp header file not found).
newbie
Activity: 4
Merit: 0
Hi FellowTraveler

Thank you for your work!

I tried to compile it with the tutorial an with the current version on git, i get the error:

[...]
  CXX    libot_la-Moneychanger.pb.lo
  CXX    libot_la-OTAccount.lo
In file included from ../../../src/otlib/OTAccount.cpp:181:0:
../../../include/otlib/OTStorage.h:1648:23: fatal error: msgpack.hpp: No such file or directory
compilation terminated.



Where should i post such errors? Because I wrote you an email because of another problem and i am not sure if you got the mail. Maybe i have the wrong mail address. (The problem, which I described in mail seems to be fixed in the current version).

How should i contact you? Where do the developers talk?

Thank!
sr. member
Activity: 440
Merit: 251
Lots of exciting news and updates!


Well I want to thank our contributor da2ce7 whose API updates have
finally been merged back into the main branch. Great job da2ce7!!

I spent a lot of time over the past few weeks updating the scripts and
java code to go along with the new API, as well as adding a lot of new
opentxs (command line) commands. (Some details below.)

As always, we've placed a huge priority on making builds available and
easy to replicate, for the Windows, Mac, and Linux platforms, in a
variety of languages.

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

Win32 builds of the OT-API!
for C++ and Java.

Zipfile:
https://github.com/FellowTraveler/Open-Transactions/downloads
With: C++ headers, .java API files, exes, libs, and DLLs.

(Source code available at same URL.)

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

FYI:  You can also build this same API for PHP, Perl, Python, Ruby, C#, D, etc.

Makefiles and MSVC project files ** ARE ** provided with OT!

Remember, it's an open-source project, so feel free to pitch in!

Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ

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

Moneychanger (Java test-GUI)

pre-built jarfile:
https://github.com/FellowTraveler/Moneychanger/downloads

(Source code available at same URL.)

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

Linux...

Thanks to contributor randy-waterhouse:

.deb, tarball, etc:
https://github.com/randy-waterhouse/opentxs/downloads

To build your own:
https://github.com/randy-waterhouse/opentxs/blob/master/docs/INSTALL-MEMO-Linux.txt#L93


Awesome!!


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

Are you a Mac or Linux developer, want to get started with OT?

Try this:

     mkdir ~/Scratch
     cd ~/Scratch
     git clone git://github.com/FellowTraveler/Open-Transactions
     cd Open-Transactions
     autoreconf -i -f
     mkdir build
     cd build
     ../configure --with-java
     make
     make install

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

opentxs -- command-line tool

The command-line tool was written in OT-script, courtesy of the
chaiscript project: www.chaiscript.com

The opentxs script is entirely contained in this file:
https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/opentxs

Specifically, all the commands that you see when you type "opentxs help"
or "opentxs list" are implemented in this one file:
https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot

(So you have plenty of easy-to-copy sample code showing how to properly
use the OT API in a software program.)

This was all written using an OT-script implementation of the
OT high-level API.

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

The OT high-level API

The complete code for that high-level API is available here in OT-Script
form:
https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/ot

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

There is also a Java version of this same high-level API:

https://github.com/FellowTraveler/Moneychanger/blob/master/src/main/java/com/moneychanger/core/util/OTAPI_Func.java

Moneychanger was built using it, so for examples of how this Java API is
used, please refer to the Moneychanger source code.

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

Using the High-level API (article):

https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases


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


Enjoy!


Your buddy,

-Fellow Traveler





P.S. Don't forget to check out the new test script written in bash.
       It's located in the Open-Transactions/scripts/tests folder.










P.P.S. Some info on the new commandline commands:





Send a direct transfer from FT's Silver account to Bob's Silver account:
    opentxs transfer --myacct FT --hisacct "Bob's Silver"


Send a cheque, drawn on FT's Silver account, to Trader Bob:
    opentxs sendcheque --myacct FT --hisnym "Trader Bob"


Send an invoice from FT to Trader Bob:
    opentxs sendinvoice --myacct FT --hisnym Trader


You could also:
    opentxs payinvoice


As well as:

...
accepttransfers -- accept all transfers in the asset account inbox.
acceptreceipts -- accept all receipts in the asset account inbox.

acceptinbox -- accepttransfers + acceptreceipts

...
acceptinvoices -- accept all invoices in the payments inbox.
acceptpayments -- accept all cheques/cash/vouchers in the payments inbox.

...
acceptmoney -- accepttransfers + acceptpayments

acceptall -- acceptinbox + acceptinvoices + acceptpayments



To create a password-protected cash purse:

    opentxs exportcash --args "passwd true"

This way, when you give the cash purse to someone, you don't have to
know their public key in advance (to encrypt the purse to their public
key.) Instead, you just tell them the passphrase and they can import the
cash into their own wallet, using:   opentxs importcash

It's pretty slick!



...More in a future episode.





















Jump to: