If the market really wants price instability, so be it.

Sure, it's easier to plan on a business activity with relatively stable prices.  But such a stability doesn't have to be artificial.  It's possible that price instability destroy businesses, but it will only be a consequence of the inaptitude to adapt to market.

I mean, say you sell audio CDs.  Suddenly the MP3 comes out.  Your product suddenly doesn't worth nothing.  So that's a huge and rapid price instability.  Are you going to blame central banks for not having printed money to fight this deflation ?

Economic factors influence prices.  They can make them increase or decrease.  Nobody should try to do anything against that.

Let me make it clear, stenography is only a way to hide data.  It's not proper encryption.  It's quite useful, though, since then you can store your wallet pretty much anywhere (any image storing web service), or even wikipedia.

But if you want to store your two images (both images are required to retrieve data) on the web, then you must use an encrypted wallet, not the wallet itself.  You might possibly use a passphrase that the image reminds you of.

Hum, would you consider using tor instead ?

Edit:  I realised during this thread that there are FOSS programs to do this.  "steghide" is one of them.

I was starting to write this but I'm getting lazy so I just put the beginning of it, in case someone would like to end it.

The idea is to store your wallet, or an encrypted version of it, into an image file.  The program creates a quasi identical image, with the data steganographied in it.   The data can be retreived by comparing the two almost identical images.  Therefore you need to store both images, possibly in two different places on cyberspace.

Requires ImageMagick to convert the file in Ascii PPM format.

You mean a lottery, right ?

I'm off-topic but :  anyone has a spare USB cable for n900 to sell for bitcoins ?

We definitely should give this a try.  I unfortunately only have shell CGI on my webserver (no Perl, PHP, Python or stuff like that) so I can't do it myself.   But I'd be glad to help if someone wants to create a test-plateform.

PS:  However, I keep thinking we should avoid making a huge monolithic application for handling with everything.  Accounting is already taken care of by several FOSS project.  IMO, we need two applications : one for clearing and one for adjudication.

Nope.  I tries to load during half a sec, and then it stops without changing anything in the page.

I'm using Arora 0.10.2 with libQT 4.6.3 on Debian Sid.

Yeah but in order to make this useful, we have to wait for someone to make a tool for extracting a key from the wallet and output it in a openssl PEM ascii format.  Gavin said that he might be interested in adding that in his bitcointools program suite.

But as I said accounting is not the difficult part.  We should separate activities of accounting, clearing and adjudicating (I may be forgetting some).

Each of them should be able to interact with one another, unix-style.

Because I'm pretty sure developpers will want their own accounting system, or they might want not to implement clearing, and so on...

Well, it's good you presented it as a beta.  Because I've failed passing through the first step twice.  With two different browsers :  Arora and uzbl.

I'm not saying we should not use accounts.  I'm saying it's a completely different application.

There are actually several free and open source accounting softwares.  Check in the corresponding category in http://www.gnu.org

What we need is a software that takes charge of exchanges.  Such a software can ignore accounting data, and focus on adjudication.

No account.

I've decided to give this site a try.

It's a two weeks auction.

http://www.biddingpond.com/item.php?id=197

This is silly.  Imagine the nightmare if every single application was using a password to protect its files.

The operating system is in charge of the file system security.  Not the application.

Hi,

I've set up an experimental bitcoin via euro cash in the mail.  Due to lack of imagination, I've called it "eurobitcoin".

http://grondilu.freeshell.org/eurobitcoin.cgi

I extract rates from mtgox and bitcoin4cash, and I offer the average ask.

It's a CGI script that allows to make reservations so there's normally no need for human intervention, apart from sending the enveloppe and receiving it.

It's written if french, since after all euro is not the national british currency, so why not writting in my mother tongue, hum ?

I'd welcome german and other central european languages translations.  If any one wants to help.


I'll attach the source code here.

I'd like to see a Unix-style program that would parse ASCII column format for orders on stdin, and would output matching, adjudicated orders.


So the usage of the program would be :

$ adjudicate < orders-file

Where "orders-file" would be a column-oriented data file with the following columns :

ID:  some random unique string to identify the order
DATE: date when the order was signed in seconds since EPOCH
ASSET: identification string for the asset/currency
AMOUNT: quantity of the order.
PARTIAL: 0 if the order can be executed partially, 1 otherwise.
PRICE:  limit price for the order.  Positive for a bid, negative for an ask.  Price is in bitcoins, of course
DEADLINE:  limit date for the validity of the order
FINGERPRINT: the fingerprint of the issuer's GnuPG public key
SIGNATURE:  a hyperlink to the signature of this order.


So there is one line for each order.   Therefore the program can be easily inserted in an pipe.

The program searches for matching orders, and determines a selling price, according to some rules that we have yet to decide.

Consider for instance those two matching orders :

A. quantity=1000, bid=110
B. quantity=100, ask=90

So at which price should the trade be done ?  90, 110, 100 ??  Should the relative quantities intervene in chosing the amount between 90 and 110 ?

What about this situation, where one bid matches two asks :

A. quantity=1000, bid=110
B. quantity=900, ask=90
C. quantity=500, ask=100

Which order should be executed fully between B. and C. ?  Would the criterium be only the date at which the orders were posted ?  Would B. be executed preferentially since it has a lower ask ?

Those rules have to be made clear, and integrated in the adjudication algorithm.

Anyway at the end, if some matching orders were found, the program returns pairs of order IDs. One pair per line.  Orders that are not valid (deadlime in past for instance) are printed on a single line.

For instance this output :

foo1  bar1
foo2  foo3
bar2

means that the order foo1 matches the order bar1 and both should be executed.  Same for foo2 and foo3.
However, bar2 is an order that the program has detected as being non valid.

An other porgram could then use this ouput to update the order-file, and then input the modified version again to the adjudicate program, while adding new orders if there are some.  And the process repeats until there is no more orders.

Here is the one I use :



I use the Private virtual encrypted directory  made with ecryptfs.

The obexftp line is to transfer to my N900 via bluetooth.

Try to think about the bitcoins you will earn when the software is done and you use it to do business.

Come on guys...  Don't you like coding just for the fun of it ?  I'm currently working on something else right now, I will release the source code once it's done, and yet I don't expect to get any bitcoin for it.

It's very easy to pay someone with bitcoin, and yet I don't think this is a reason why we should pay for everything.

Moreover, I actually tend to think that the code is better when it is done for free, because the developper really enjoyed his work, and did not do it just for the money.

Pretty cool.  A gold coin like this would be nice.

Anyone knows someone who could mint it ?