Thanks, I went ahead and opened ~200 0.1 BTC VIR lending offers for 120 days to see what happens. Interestingly now 0.2 and 0.1 of these are lent out after half a day, but NOT the ones with the lowest offer ID. As these offers were identical, I hoped to see a pattern emerge on how these will be selected by the engine. Weirdly enough it took them from rather towards the end (meaning the newest positions - but not really the newest, rather it selected 3 in the last 10%) and not sequentially as I suspected.

Also thanks for the explanation what means what in the ledger.

Gründung einer Crowdinvestmentplattform (man kann Unternehmensanteile kaufen, so ähnlich etwa wie Kickstarter + co nur eben ohne Produkte und mit Genussscheinen), von einem Gründer dieser Plattform, ging um das österreichische Äquivalent der BAFIN - die Finanzmarktaufsicht aka. FMA: http://www.fma.gv.at/

Die haben dann eben einen Anwalt beauftragt der das Geschäftskonzept nochmals auf juristisch umgedichtet hat und dann hat die FMA Mitte diesen Monats dann auch gesagt, dass das konkrete Modell ihren Auflagen entspricht. Sie wollten aber keine Hilfestellung geben, wie man dieses Modell erstellt oder wie ein gültiges Modell aussehen könnte.

Zumindest anderswo kommt dann schnell mal die Antwort von der Behörde: "Wir sind ein Aufsichtsorgan, keine Beratungsstelle. Schönen Tag noch."

Hm, what's actually the best way to lend coins?

Since VIR seems to be preferred atm. I guess VIR it is for the rate - but how long should the period be?
Positions can be opened for 1, 7, 14, 30 and 60 days. I guess it would make sense to rather offer 60 (or more) days as lending period if you want to lend for some time (especially with VIR). On the other hand I'm not sure if the system matches a 1 day position with a up-to-60-days lending offer or if it also selects by duration or amount (if there are several VIR offers). Could you please elaborate how the system selects from several lending offers that are at the same rate, but different amounts and durations?

Another thing:
I offered 15 BTC VIR 10 days and 5 BTC VIR 2 days (both renewable I think) yesterday.
Today I have suddenly an open offer for 19.99 BTC VIR for 10 days and an "Interest Payment on wallet deposit" of 0.0009 BTC (it looks like the amounts in the UI get rounded to 2 digits, so it doesn't show up).
After playing around a bit, I found out that I can offer the same amount multiple times, which means I can inflate the order book arbitrarily. I guess my other offers become canceled/inactive once an offer is actually filled - but still you might consider a change there? I have VIR offers for 119.99 BTC open with only 20 BTC backing these... I could fake thousands of offers at really low rates probably leading to others trying to underbid that "wall" with only very few funds behind.

Another thing is that I'd like to have historic data on VIR:
I got stuff like "Executed at vir(5.0): was partially filled at vir (1.0), partially filled at vir (0.98422983), partially filled at vir (5.0), partially filled at vir (3.01577017)" and even "Executed at vir(19.96814999): was partially filled at vir (0.02185)"! This seems like quite a bit of jumping in that rate.
Also from the history I cannot see (other than looking at the newly posted lending offer, which interestingly stayed the same on the second one) how much of the BTC I offered I was actually lending out. As far as I understand, offers can be partially filled after all.


Edit:
If positions are chosen by time stamp (e.g. take all offers that are open for at least x days starting from oldest to now), it might be a good strategy to create as many small offers as possible. If I lend out 20 BTC and only 0.01 BTC is taken from that, a new offer of 19.99 BTC gets reposted as far as I understand and I loose the old time stamp. In the extreme case I should lend out atomic positions (single Satoshis) to make sure all my funds are optimally used if renewed in such a scenario. Maybe it works differently, but so far (from logs) it seems like somebody took a loan of 0.01 BTC from one of my offers and it got renewed.
Oh, and 5 minutes ago suddenly my offers vanished ("insufficient balance, was: active"), 35 minutes after being posted.

ReactOS

Also of course the Hurd!

Perfect, it works now!

Edit: It would be great if unconfirmed transactions also show up (I trust that the transaction gets in the block chain but it's nice to know that your software recognizes it as well).

The reason against miners mining their own money as fees is that if a block gets orphaned, some other miner can claim the money from these transactions.

High fees to drive out lower transactions would work in probably any limitation scenario. If you invest 600 BTC per hour in the current network, you're also probably able to drive out a LOT of transactions.

This is what greets me already for more than a week - any eta. on when I am able again to throw money at you? No, I don't have or want an MtGox account to get codes from there...

Their point is that computers are getting so insecure that it doesn't matter if they communicate encrypted or not - not that crypto gets broken.

E.g. somebody hosting a wallet on a server not at home makes it easy for the hoster to spy on that. As long as security measures are followed, your coins are safe too.

It kinda boils down to: "You can't trust the others to handle their stuff properly and it gets harder and harder for you to handle your own stuff."

Also one can use perceptual hashes to verify that your frame actually looks similar to the picture before and after or to a low-res solution.

It might work for a "Kickstarter" style software release though:

Everybody can download the software, encrypted with the same key.
As soon as at least xxx BTC are in address yyy, these are transferred to a vanilla (previously unknown) address which is the key to unlock the software. No activation servers needed.

Might also work for something like "I'll make the program OpenSource for XXX BTC".

Ok, to render with modern algorithms you tyypically need the whole scene, no matter if you render only a single pixel, a 64x64 bucket or a 4k frame.

Just hold your fingers like a square in front of you (away from the screen) - probably you still can see indirect light from the sun that might even be hidden behind clouds. Similar a lot of things that are hidden by your fingers still influence the "bucket" that you see (shadows, reflections...).
Similar to this, even if you only render a small part of a scene, you need to consider a lot of objects that are not visible --> you need to transmit a lot of data.

You described how render farms work quite well (splitting into frames and letting each node work on them alone), still this usually requires so much data that most render farms work in a LAN and have big storage servers in the backend for large textures etc.

Another issue is that you need to give out things you might not want the person rendering the frame to know (e.g. a frame for the upcoming 2nd Hobbit movie). Homomorphic encryption is not that far yet, but might work out in the future for even more general services (then you just load a blob of data, process it and send it back without ever knowing what you actually did)

A commercial platform using BURP as far as I know:
http://www.renderfarm.fi/

What kind of weird "game" is that?!

You have a 3.125% chance _additionally_ to the chance of not finding a greater fool within 1 day to loose all your money. Also they seem to have a hot wallet (via blockchain.info API) to send automated payments. Time to wait for the next Wordpress bug then...

You can develop a Bitcoin payment module to http://burp.renderfarming.net/.

Can a miner be forced to include free transactions or to drop certain transactions by publishing "better" transactions with this approach?

Also I like it because it leaves the issue of block size aside. On the other hand maybe that might be a problem?

Of course they are spendable, but the fees required to do so might be too high in a limited block size scenario.

Also they might be used as fees as far as I understand, but probably again even just including these with the intention to just give them to miners might be more expensive than the space they take up in the chain.

They can't be pruned because they CAN be spent with 0 fees and/or free transactions.

Well, Satoshi's Dice seems to me like going to a casino, exchanging one USD in chips, playing a round of a game, changing back to USD, changing another USD to chips etc.

This described attack might also work with p2pool by the way, then you only attack with your own hash rate though. Still useful for people with ASICs at their hands and you can also mine a bit larger blocks there, as you will relay blocks at a lot of different places in the network as a bonus.

There is no such thing as a minimum fee in the protocol, only in the current rules of the most used client. The minimum fee is either 0 or - if you say 0 is "no fee" - 1 Satoshi.

Maybe testnet could be more prominently placed in the client, so people can play around (which is mostly the reason for 1 Satoshi transactions I guess), also with more meaningful amounts.

With the approach taken here, it might be possible to not only passively act, but actively fight SD spam by shifting the odds in your favour if you really don't want to see them continue with their business.

Edit: Since blocks are anyways small, it might even be possible to just mine "normal sized" blocks as well, to not be too obvious.

All in all, it will be something like "check if transaction X exists, if true: do something". This can be edited to: "check if 1==1, if true: do something"

If you actually distribute software that is uniquely encrypted (every download is different), it takes only 1 paying customer who distributes the unencrypted version and you have the same problem.