Looks like both the bet on betsofbitco.in and ABSORB will very soon pay out on the long side - 5.95 USD per BTC reached...
http://bitcoincharts.com/markets/mtgoxUSD.html

Reading threads instead of "subbing" them helps...!

https://bitcointalk.org/index.php?topic=74049.msg959643#msg959643

I'd recommend to follow up on my questions in https://bitcointalk.org/index.php?topic=77650.0 - It's really uncanny, as I planned to do something similar ("bitdust" was even a ticker symbol I considered) as soon as the dividend API would be released. Before that it wouldn't really make sense and I hate poor and/or rushed execution...

Anyways, you can calculate for each second since the blockchain started how many BTC 1 MH/s (or 1 KH/s) would have generated... then just sum up accordingly for hours or days and pay as dividend. All you need is either a running bitcoind + asking for the block headers via RPC or running bitcoind + armory and having it already nicely packaged. Libbitcoin might also work, I haven't tried that one yet.

If I only read "some day I'll do the work to pay out correctly" I start looking like this -->
Even if it's tiny amounts of money, you're still resposible for it and should put in some effort (it's not even hard, my scripts were finished in under 2 hours) instead of looking for a quick payment.

Is that mail address at least one from your provider or similar with your real name on it or something like "ognasty @ mail.ru"?

To determine that somebody has downloaded a file though, service.com needs that checksum quiz file... with the "flattr" model, service.com doesn't even need to know/care which file was downloaded. I get your point though, but I guess I have to think a bit more to come to a solution.

Nef was asked multiple times for:
* Placing buy/sell orders at certain times in advance
* Paying dividends at certain times in advance
* Calling back bonds at certain times in advance

I think he knows and I think he's swamped in work + support questions atm. Hopefully he finds some time to do some development work on GLBSE, the recent API for outstanding shares was a great start!


You don't need git, it was just used as an example. Simply google "curl" and your preferred platform (windows, linux, os-x, freeBSD...) and you'll find an executable.

I bet my GLBSE bot is more precise than anyone pushing buttons...

Just google it, curl is a command line program (there are also Windows versions) that is used to interact with webservers. You can then (with Windows) put the line posted above in a batch file and have the task scheduler call the batch file at exactly the time you specify. If you learned how to use computers back then, this should anyways be kinda familiar...

To find out about lag, you can try to put up test orders at 99999 BTC or so and check how long it takes until they show up (maybe 1-2 seconds I guess?) so you can then issue the sell order at xx:59:59 to have it at exactly yy:00:00

A different approach could be kind of a "flattr" model for paying uploaders.

Seeders of anything run a client that replies with their ID and downloaders run a client that asks any connected client for that ID (it either gets ignored or someone replies). Every now and then a list of "I loaded 1 MB from X, 40 MB from Y and 100 MB from Z" is uploaded to service.com.
Service.com then holds funds of downloaders in escrow and pays them proportionally to X, Y and Z. If downloaders don't tell any data, their funds for that time frame get donated or evenly split or split according to some rating (glicko2 sounds really cool) or . Stats should be as fast as possible available but aggregated over a week or even longer (2 weeks, 1 month...) to have meaningful data for payouts for most participants.

To get more funds, it is of course better to prefer clients that ask for an ID. It can be even 2-sided, so seeders can also see if they really got paid something from A, where they uploaded 1 GB to or if A was just asking for their ID but never submitted a report.

This would again require some trust from seeders, that someone asking for an ID will really pay something and requires 0 trust from leechers (as they anyways can use the swarm as usual - but have a chance to get some much better seeds if they ask for IDs to pay towards). If the updates run in near-realtime, trust can again be increased over time ("I uploaded 1 MB to A and a few seconds later A rightfully told service.com about it - more bandwidth to A!") and even without some fancy traffic shaping stuff it's simple to just seed some popular torrents and potentially gain a few coins too.

This way it doesn't matter if there are fakes or not (they can only pay anyways) and service.com also doesn't need to care about bandwidth offered as it is i the best interest of seeds to offer more bandwidth to users of service.com.

The above would be the other extreme - big torrents with few leechers would be not very popular, unless there are some leechers that really offer a lot for that traffic. Just keeping the torrent alive though (no leechers atm.) is not really attractive, as there's more money to earn by loading + sharing the next file and actually uploading something.
Maybe these 2 extremes (it's already enough holding a file and not even seeding it vs. upload is everything, even just loading 1 part of a popular file + just sharing it can net you a lot) can/should be somehow combined for different user groups or so?

That's why I called it simple - service.com would only issue challenges + try to connect via BitTorrent to the seeds. If there is a checksum error or not even a torrent client running, no money for them! The hassle for downloading the torrent files + keeping them is hopefully enough though to let them really seed as well.

Ideally, other clients/downloaders would report from whom they loaded how much. This data unfortunately cannot be trusted though and I still can't really think of anything how to make it trustworthy.

Edit:
Maaaaaybe you can trust "I have loaded x MB from ..." data if the person claiming this can also solve checksum riddles. It would still be trivial for seeders though to solve these riddles and claim high upload rates from some random clients.

Because that file could be sent to someone collaborating with the uploader (Seeder X) who doesn't really download the data but now has every possible answer to the challenges. He would only get the money for the files from the uploader, but maybe also some rating as "that awesome seed that has 0 CRC errors + stores multiple TB for theat uploader" that would probably be part of the platform too.

I wouldn't throttle transfers from symform to symform people checking on my upload capacity, only to anyone else - so if they check me out, I'm that 1 MB/s upstream candidate they always want to see. If anyone else actually wants their data though, good luck with that!
Symform can't trust complain reports of these clients that I'm slow, otherwise I could write a client that complains about anyone else and rate these down.

About markets - this could very well be automated. Just set a price you're comfortable storing data at or a price you'd like to charge at least and let the service handle the rest. The hard part is really enforcing these contracts and making sure they are followed, from both sides.

A simpler version that can be done without handing too much risk to service.com but that should still be fairly secure would be to hand the random checksumming still to the uploader (which in return however could provide that data to be used to fake seeds). Uploaders then send a torrent file (or better: magnet link) + a file with the random checksums to service.com, send some BTC + give a timespan of how long this file shall be seeded.
These things (magnet link + BTC pledged) then get published + a verification client, that has to run and that handles the checksumming part (can/should be open source) can be loaded. In the verification client, seeders enter their payout address + a treshhold (say 1 BTC) and similar to mining pools, as soon as their balance reaches the treshhold, they get their money. Also if they don't seed anything for 14 days, and their balance is above "bitdust" levels (say 0.005 BTC?) they get their remaining balance. Service.com only has magnet links and random checksum data and doesn't require any data from it's users other than payout addresses + IPs (for connection checks).

This could be used for any kind of P2P network actually, BitTorrent, eMule (ed2k), several of the anonymous networks like WASTE...

Prices would set themselves because it would be something like: "I offer 1 BTC over 1 month to all the people seeding this torrent". Every hour there's a test for anyone claiming to seed that file by service.com: A random checksum challenge + trying to check out if a bittorrent client is running and seeding the file in question (yes, one can lie about that, but at least it takes some effort). If these 2 criteria are fulfilled, 1/720 BTC (there's 720 hours in a month) gets split between all seeds. If they reach a point where they don't earn enough, they'll just drop out. There can be live public stats and maybe even bonuses/penalties for people (not) failing checksum tests.

Far too overvalued for my taste, but as you said the market shoud correct itself anyways.

Good luck with Rugatu, it seems like an interesting concept - hopefully it's really easy to use and you don't have a lot of coins in your hot wallet...

90% PPS, 110% PPS, 1% PPS, who cares?!

You could just offer 1% PPS of 1 MH/s instead of 100% PPS of 10 KH/s...

Odd numbers just make it more difficult for investors to calculate how much the "standard" of 1 MH/s would cost.
Also your calculations seem weird: Why do 1% of something generate completely different amounts of BTC and not just 0.01 * [revenue of 1 MH/s]?!

Also I don't get why people should be discouraged to hold 100 bitdust shares instead of 1 YABMC share for example. It would be even better, since there might be more liquidity.

For popular "files snatch and leave" is more of a problem, slow seeds are more of a problem with files that have only few seeds to begin with. If you upload pictures of that sister to a handful of people and they all decide they would rather seed other files faster, there's no chance for you to get these back quick enough.

Symform and others deal with this by dispersing files wide enough that this doesn't matter (you can afford to load a few tiny parts slowly while you're busy downloading from seeds that are not jerks).

Yes, something to ensure seeds just have the file might already be enough, as the bandwidth might be anyways cheap compared to the cost for storage and too popular files can be dropped as you said. If it isn't though, we have a problem. It might be enough though, especially for initial seeding of a potentially popular torrent. These tend to violate copyright laws sometimes though...
This is actually really a problem for service.com, as it MUST be the only one knowing in advance which parts of the file shall be checksummed and what the sums are. This means service.com has to have every file on it's HDDs at least once. This means, files either have to be encrypted with a key not known to service.com (similar to one click hosters) or filtered by service.com.

10 US cent per GB per month would be ~42 Satoshis per minute by the way, so cheaper rates (e.g. 2 satoshis for 1 minute of seeding 1 GB) are possible and feasible at least. 1 Bitcoin would then seed a bit more than 1 TB for 1 month. Maybe a bit too cheap, but offering a market for that might anyways quickly establish prices.

Aus den EXIF-Daten der Bilder:
^^^
Klingt ja sehr nach einem Serversystem... NICHT!

Symform doesn't seem to meter bandwidth provided, so I could just offer some storage, download fragments and rate-limit the port they use in my router to 1 KB/s. In reality I gain online space for that but don't contribute anything meaningful to the network.

Their approach looks actually quite similar to tahoe or Wuala (back when they were P2P) or the japanese P2P sharing system "perfect dark".

Just like BitTorrent they depend on user's generosity and/or not too many freeriders. Once you bring money (even "internet funny money" like bitcoin) into that equation, it could be an explosive mix...

Yay, live outstanding shares 4tw!

Thanks a lot Nefario!

Maybe a system like this should include a share ratio though - something like "1 MB hosted can generate up to 5 MB upload during the last 7 days, after that you can shape or even deny access" with higher ratios obviously costing more. This would address the "storage vs. hosting" issue, as hosted files have to be stored somewhere and stored files need to be hosted to be available on demand. The difference is that hosted files will probably have a lot more traffic but might be smaller than the other way round.

To circumvent the traffic meter issue, it might be possible to split payments in 2 parts:
1 part for storage (checked via checksums from service.com) paid by service.com
1 part for traffic, measured by downloaders and paid by service.com

The downside would be that downloaders also require an account + deposit at service.com as well as some traffic metering software - the upside would be that there can be no (useful) faking of traffic, as the downloader simply says "I loaded 12 MB from node 1, 16 MB from node 2 and 100 MB from node 3". If he wouldn't run the metering software, he wouldn't be able to get unshaped downloading speed in the first place, the only thig he could do is to lie about ratios (like he loaded 100 MB from node 1 and 12 MB from node 3 in reality) or nodes (he loaded nothing from node 3), but both of these scenarios would not benefit the downloader and he'd have to pay anyways for traffic consumed.

The implementation could be like this that a downloader says at service.com that he wants to download 100 MB of files. Service.com runs a bitcoin-style block chain (probably with faster blocks and not publicly mined) and transfers a number of 1 MB "coins" to the user and charges his account for this. As the user downloads (seeds can check that he actually has some money by requesting a message signed by the private key of the address that holds the coins), the metering software sends out DL-coins to the seeders' addresses. This way they can see after some time, that the user is really paying up and trustworthy, so he should be able to quickly build up trust within the swarm. It's even possible to gain back some money for the user, by seeding the file himself while loading and publishing a seeder address.

Once the download is complete, the user can transfer remaining DL-coins back to service.com (there should be some slight overprovisioning to account for CRC errors, rounding errors etc.) and gets some BTC back to his account there or he just accumulates them for the next time.

Seeds can do the same (redeem DL coins for a fixed price or bandwidth).

The balance of BTC stored at service.com can be requested at any time, service.com would act similar to a mining pool nowadays (collecting lots of tiny transactions of some value - mining shares - and paying out aggregated payments to reduce blockchain spam and bitdust issues).

1 DL-coin could for example be equal to 1 satoshi, this way conversion would be easy and there would be no decimal point numbers for people to worry about.

Why have different coins, not BTC?
* no block chain spam
* nano/picotransactions (1 MB of traffic is far below the treshhold for transaction fees)
* quicker confirmation times (you don't want to wait for an hour until you can see that the leecher is really paying up)
* centralized mining allows for a "1 block = 100% confirmed" style of mining but it could still be expanded more easily for more than 1 service provider compared to a pure server solution

What would be the risk for seeders?
* Some leecher shows that he owns 1000 MB worth of download, starts loading and after a few MB still doesn't pay anything. Solution: Traffic shape him until he pays up (confirmation times would be likely a few seconds or so, so not much to be wasted)

What's the risk for leechers (downloaders)?
* A seeder sends bougs data. Solution: Don't pay after getting the data
* A seeder is too careful and wants to see you pay other seeders first, before offering any data and you can't pay anyone else since they all are too cautious. Solution: Probably people will register seeders for the purpose of giving some MB away and then seeing if you pay up - the big advantage for that is that you are then likely to be a preferred seed by the leecher and can earn more through the traffic. Maybe it can be possible to detect such situations by service.com (simply act as leecher and ask seeds if they are fine with offering files in advance) and flag such files as opportunities to be grabbed. This is somehow an unsilved issue and depends on the ecosystem of seeders that arises... the monetary risk of handing out a few MB for free is however probably smaller than the potential profit on being the first seed on the list.

They are actually already there.

Format:
dividend,2012-06-13 00:01:08,x.xxxxxxxx,JAH,,,,

Maybe you haven't received any yet?

True, these hashes can't be used for testing though, as they are public knowledge already.

To request seeds for a torrent file, you send the SHA1 hash of the whole list of SHA1 hashes (and some other data - looks kinda similar to the bitcoin block header) called "info hash" to a server called "tracker" and state that you either have these files available or that you want to have a list of IPs who have these files.

All trackers know is that infohash "abc123" is seeded by IP 1.2.3.4:1337. They know nothing about  file names, how big the files are, if 1.2.3.4 even HAS the file or is a jerk pretending to and they have no means to verify any of this. They are just plain stupid databases on the internet. This gets more and more replaced by DHTs nowadays, which are in the end just a distributed database, meaning some nodes feel responsible for the infohash "123456" and others for "654321" and you get your data from these nodes instead of a central server.

As it would be near impossible to include monetary transactions into the bittorrent protocol itself, we'd rather need to extend it and just use it for transport.

Modifications would have to include:
Ability to allow, traffic shape or ignore hosts on-the-fly based on if they are paying or freeriders.
Central trusted element (service.com) - I'm not 100% sure if it can be distributed without having a server yourself that constantly does these integrity checks. It could be distributable in that sense though, that there are multiple services to choose from and you can host one yourself (just like torrent trackers but with a lot more bandwidth requirements)
Something to verify upload speed. This is the biggest question mark for me, as it would be trivial to have a central server that downloads files from nodes to check on their speed - but it would be trivial for them to just grant this single node the high speed, everyone else has to live with 1 kb/s.

@markm:
How could I make sure that any of these offers floating around are actually worth even the 1 USD/month/100Gb they ask? Going offline, not offering any significant bandwidth, destroying data, taking a run with the money...
On the other hand, how would I deal with the fact that if I offered to host 100GB for 1 USD/month it might be the case that I never get paid or have to deal with 100s of GB upload because suddenly I'm hosting the newest season of Game of Thrones for the whole internet...

That's not a collateral, at least for me, more something to cover fees, giving me 2-3 free 1MH/s mining shares and to make sure he's able to deposit to the address mentioned.

An honestly - if he really risks his GLBSE account, forum trust and a lot of trouble just for ~20 BTC (in my case, can't speak about the others) or even less (if the shorting is successful) plus a few coins in total for dividends... well, that's my risk after all.

I personally am not THAT "long" on mining bonds in the sense that I guess they will be sold for 1 BTC per 1MH/s soon, but I think they will not collapse as much as some predict will happen with an ASIC announcement around the corner. Double dividends for that time frame seems like a fair deal to me (and I also didn't give away all my mining shares or shares that I own...). I would probably have more money on the table if I were spending an evening in Las Vegas to put this into perspective.