@jorgen, Good idea, but I think it's better to have a introducer or helper node then instead of a storage node. The amount of disk space would be too limited to be useful I think (25btc per week for 100MB?). They might even be able to collaborate, they could use the grid to add redundancy for their servers (they use raid1 now) or as a service for their customers in return for a permanent introducer node.

@Bit-Lex, I wouldn't install a linux-VM if you don't need to (you could better use the disk space for the grid itself ). If you scroll a bit further down on the install page there are instructions on how to install tahoe-lafs manually. You could try that.

About the storage encoding:

The storage encoding contains two values, often written down as a, for example, "3-of-10" value.

In this the 3 means the "split". A file is split in 3 shares (a 100 MB file would each have 33.3MB per share).
The 10 value means the redundancy. Put each share on 10 nodes (doesn't need to be the same).
If one node contains one share of your file and it goes off-line you have 9 nodes left that still have the share.
3 shares (on 30 nodes at most) are needed to rebuild your file.

Also note that the 3-of-10 value gives a total file size of 300MB.

3-of-10 is a quite conserved value. Personally I think it will be better to have some other values, because of the nature
of our grid: many users with limited availability of shares.

How about 4-of-20? (100MB file will be 500MB total)

I will be initially providing a node with around 10GB of space (partially on-line).

Having setup a Tahoe-LAFS node. Zooko (one of the developers on this forum) gave the following tip:


So, with this topic I'm starting to setup and coordinate a Tahoe-LAFS grid among the bitcoin users. It's goal:

- Setup a grid that everybody can join and use (e.g. for backing up your wallet.dat and other files).
- Encourage the Tahoe-LAFS developers to put some more effort in a bitcoin integration for Tahoe-LAFS and help with ideas of how it should be implemented.
- Use the grid as a test bed for the bitcoin integration.

What do we need:
- Storage nodes, the more the better. Can be desktop systems.
- Introducer node(s), to connect the storage nodes. I think we need a few systems that are permanent on for this.
- (Optional) Helper node, to have things uploaded more quickly for users with limited bandwidth. Also a system that is permanent on and has a large bandwidth.

What we need to discuss before we start:
- The storage encoding for the network.

Documentation for starters and how to set things up:
About: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html
Install: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/AdvancedInstall
Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=220018

I've got a storage node running now (Nicknamed "Sjeng"), connected to VolunteerGrid.

@Zooko, any news on the bitcoin implementation in Tahoe-LAFS?

eeehhh..

I haven't encountered that yet.

<edit>I do notice that sometimes the reload hangs.</edit>

Ok, played now a few times.

One thing. Don't have it refresh on the result screen (I walked away and came back, empty grid and a lost game. Would be nice to see what the other player did). And show both individual selections (both users).

Ah wait, they work on the whole grid.

How about pay price compared to grid size? Small grids cheap, large grids expensive.

Example:
3 squares = 0.10 btc
5 squares = 1.00 btc
7 squares = 10.00 btc

I've read the description, but only get half of it. Are the squares only compared horizontally, or also vertically?

Anyway, I've put in my squares .

Nice.

I don't use MtGox, but the website says:

Mt. Gox charges no fee and is free to use. Donate a few BTC to help keep it that way: 1EuMa4dhfCK8ikgQ4emB7geSBgWK2cEdBG

Why not use that?

What goes up...

That and the first bitcoin bubble?

Does this mean we'll get a drop in difficulty soon?

I already thought about this problem. I came up with this idea:

Have bitcoin (or some proxy program (I was thinking about this for my pybitcoind-desklet program) in between) start a dbus daemon that accepts "bills". These "bills" list the receiver address, the amount of bitcoins, the program sending the "bill" and possibly a transaction description. On receiving the receipt, the user gets a pop-up/notification about the "bill" to pay it and the user is free to accept or decline the bill. After that the money is send or not.

Via this, possibly every program has a standard interface to connect to for sending bitcoins and there is no direct connection to the rpc interface, so malicious programs can't do any harm (e.g. sending rpc commands that it isn't allowed to do.

Which comes down to something I was thinking about this morning...

We have now many people offering their services for bitcoins. That is fine and all, but how about post (other topic) if you NEED something and you are willing to pay by bitcoins (tell how much you are willing to spend at most). A bit like the pizza topic some time ago, I think that one was quite successful.

I heard octopus Paul is retired, you're already looking for a replacement? Did you try Knut already?

I know, but it was more meant as a pointer.

Because it is the only option?
And people who want to donate differently wouldn't bother the hassle.

Somehow they don't seem to be that big yet (not as big as bitcoin):

metacurrency : no real software, only some flash widgets.
opencoin: academic researcher project and has lawyers, lot of info but no real downloadable implementation
github: server and client code, but looks alpha stage, no gui, no real website, centralized?

Of all 3 the github one looks the most promising alternative, but none seem to have places to spend the currency.