Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: passerby on June 13, 2011, 10:18:25 PM



Title: Bitcoin meets Open Transactions
Post by: passerby on June 13, 2011, 10:18:25 PM
Are there any services online that combine Bitcoin with David Chaum's blind signing protocol?

So far I am aware of only one, http://blindbitcoin.com/ (and it appears down from where I sit)

The reason I ask about whether anyone else is working on bitcoin-backed Chaumian currencies is that me and a group of friends intend to start one, based upon Open Transactions, and  are quite willing to cooperate, thus standing on the shoulders of giants if said giants are already present in the field of "blinded" coins :D


Title: Re: Bitcoin meets Open Transactions
Post by: passerby on June 14, 2011, 04:29:21 AM
*cough*

Is bumping frowned upon in the community?


Title: Re: Bitcoin meets Open Transactions
Post by: Isosceles on July 02, 2011, 05:17:35 AM
There's the MoneyChanger Java GUI. I haven't seen any websites using it yet though.


Title: Re: Bitcoin meets Open Transactions
Post by: markm on July 02, 2011, 05:44:35 AM
For me the market parts are important enough that I keep putting Open Transactions on the back burner, though I also have a problem in general with getting things online that require compiling and/or require an open port. (I can compile at home but not open ports; I might be able to open ports at a third party hosting site but in the past have not had good experiences compiling on them (supposed Linux hosting turning out to be BSD purportedly "binary compatible" with Linux, for example) and in any case putting financial processing on a machine I do not physically have access to, that someone else *does* physically have access to just doesn't seem real smart. (Maybe even less smart if they or someone they know might even know what bitcoins are...)

In practice I thus figure I need two things before going online with something using Open Transactions: one, the market functionality, two ability to run the server from my own physical location.

-MarkM-


Title: Re: Bitcoin meets Open Transactions
Post by: mouse on July 02, 2011, 06:01:21 AM
I think a few people are working on OT/bitcoin apps in the background.

I'm considering doing a full Java implementation (I know theres already bindings), just at the reading stage now. Have a lot of catching up to do (I like to reasearch the history of every development whenever i find out about a new technique. As you can see I'm easily sidetracked).


Title: Re: Bitcoin meets Open Transactions
Post by: Anonymous on July 02, 2011, 06:05:49 AM
I think glbse.com is based on open transactions or can be ported to it.


Title: Re: Bitcoin meets Open Transactions
Post by: markm on July 02, 2011, 07:15:19 AM
Yes, they used Open Transactions code.

I don't know how much they had to change it though, for example OT claims it needs to use larger number of bits key size to be ready for doing real work, the bit size so far used is just kind of proof of concept not for real use with real funds.

So that'd be my possible number three, if I agreed that the current number of bits isn't enough.

(I am not sure if Martians would worry about that, would earthlings be so foolish as to risk war with Martians by attacking Botcoin? ;) :))

-MarkM-


Title: Re: Bitcoin meets Open Transactions
Post by: marcus_of_augustus on July 02, 2011, 07:33:10 AM

Seems like a simple bitcoin-namecoin exchange would be a good little test case for an Open Transactions implementation.


Title: Re: Bitcoin meets Open Transactions
Post by: markm on July 02, 2011, 07:42:49 AM
Yes indeed. It was simple little exchanges like that that led me to build Open Transactions API calls in tcl into one of my tcl-based "eggdrop" IRC bots. I figured since I already have bots able to exchange between bitcoin-like currencies I might as well also put Open Transactions into the same type of bots.

Also I might not be the only person who has problems with the idea or practice of running self-compiled and/or financial daemons on third party servers, so figured I might not be the only person who might find IRC to have certain virtues.

(If we want to be by the people for the people having it easy to run stuff from home seems not too bad an idea in some respects.)

-MarkM-


Title: Re: Bitcoin meets Open Transactions
Post by: flok on July 10, 2012, 12:33:22 PM
Yes indeed. It was simple little exchanges like that that led me to build Open Transactions API calls in tcl into one of my tcl-based "eggdrop" IRC bots. I figured sine I alreday have bots able to exchange between bitcoin-like currencies I might as well also put Open Transactions into the same type of bots.

Is that irc bot opensource?
If yes: where can it be downloaded?


Title: Re: Bitcoin meets Open Transactions
Post by: markm on July 10, 2012, 01:18:41 PM
No one ever actually used any of the IRC bots, so one by one they have gone offline, I am not even sure exactly why since I didn't actually turn off their entries in the crontabs of the various usernames running them. I think eggdrop just tends to eventually corrupt its user file, as while I did care abou them I did have to restore the user files of several of them to keep them working. Quite likely since I stopped caring they have one by one corrupted their user files (which, since they have no users, mostly contains their entries about each other so they can network among themselves).

That corruption isn't a dealkiller since part of the purpose of their networking among themselves is to share their users, so as long as you can find one still running it should know about you thus let you transact exchanges between the various blockchain-based currencies.

However, I never did get the bot I tried to build OT's TCL API into to work. It has turned out in the intervening year that actually OT needed a lot of work, we found some deep problems and fixed them but by then the market had made it clear that IRCbot-mediated exchanges were not wanted/desired.

My focus has thus, in that intervening year, moved on to running an actual Open Transactions server, and the debugging and so on has been focussed on getting that, and a demo client demonstrating how one could talk to such a server, up and running and, recently, also able to be built using autotools and having windows binaries ready to download.

I have a thread in the projects section about my Digitalis Open transactions server (https://bitcointalk.org/index.php?topic=53329.0) which if nothing else may serve to chronicle some of what has been done during the last year or so.

User balances have survived admirably, they are very robust, the system works well in that respect. The last few months have mostly been focussed on implementing paranoid security so that a user's machine never lets the passphrase used to decrypt the user's private keys get written to disk. Right now custody of an intermediate key derived from the passphrase is in the process of being delegated to the "keyring" services of the various supported operating-systems so that even that keyring does not store the actual passphrase, just something derived from it that Open Transactions can use to decrypt the user's private keys for a configured number of seconds. It has taken a lot to get this far with that degree of paranoia, and all the constant testing implemented by automatically run scripts has halted ever since the paranoia reached a point where the scripts could no longer work unless a human actually "held their hand" every time they run, providing the passphrases over and over again at all times of day and night when the scripts got run by the scheduled-tasks service (cron, as I use Linux).

The IRC bots that actually worked did not use Open Transactions; they simply called shell scripts that communicated with *coin daemons, using the verified "nick" of the IRC user as the "account" name in the wallets controlled by the *coin daemons; and actually I do not really know whether they did really work as no one evidently ever managed to create an account on one, albeit only one or two attempts that I know of were claimed to have been made, in neither case persistently enough to proceed to an actual test/exploration to try to figure out what their problem had been.

-MarkM-