Actually I deem the actions or expressed views of a lot of people here on the forum worse than the ones expressed by the Iranis I know...

Why should I care if someone could potentially have owned my coins before me, whose views I don't agree with? I once saw a nice article about people who contributed to open source projects who have and had questionable views on the world (and even here, I doubt a lot of people would agree with the personal views of LukeJR for example). In the end money (and code) does not express anything, only the way it's used.

Check the code of bitcoind for that...
https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp

The latest one currently is block #210000

Actually I searched a bit (on the wiki, not the code) and didn't find a clear answer to how the "best" branch is selected, other than that it has to be the longest, it's difficulty has to make sense and the timestamps probably also shouldn't be more than 1(?) hour in the future compared to the local clock on the PC.

Making the difficulty low and recalculating from genesis makes it very easy to build a _longer_ branch, it won't be recognized as the "main" branch though, as Meni said it seems to be based on total difficulty as well.

Edit:
I thought the thing "enforcing" the higher difficulty would be that a higher difficulty produces a higher block height, since there are more than 2016 blocks in 2 weeks. This would mean that a longer blockchain with valid timestamps + matching difficulty calculations was more difficult than one that is shorter but still makes sense difficulty wise. I didn't know there were explicit calculations towards this as well.

I can stay on difficulty 1 far longer than mainnet, then towards the end quadruple the difficulty each 2016 blocks. Also every time mainnet goes down in difficulty, a second chain actually doesn't have to follow that bump and can gladly ignore it.

Just calculate "bitcoin time" with 2016 blocks = exactly 2 weeks since genesis and then calculate how far ahead the bitcoin clock is - that's the difficulty you have to beat.

Anyways, it might forever stay academic, since satoshi fixed this issue already in 2010 by including checkpoints of the then current chain into the main (and back then: only) client. It might be possible to attack other cryptocurrencies or weaker Bitcoin implementations though.

Bitcoin builds on the premise that it's REALLY hard to do this.

Your suspicions are correct in the sense that this could theoretically be done, just like theoretically someone could counterfeit perfect dollar notes that are in total worth more than all other "real" dollar notes. In practice this is very hard to achieve.

If you just want to cause a disturbance in the bitcoin community, just re-mine the whole block chain with difficulty 1 blocks (and increase towards the end) - might still be quite hard to catch up, but everytime the difficulty goes down, you save on hashing power. There are still quite a few old clients out there that have no checkpoints compiled in besides the genesis block, so you can still cause some problems.

Kaufen, weil man die Coins braucht (als Anlage, um damit zu zahlen, als Hobby...?!), verkaufen, weil man Euro oder andere Fiatwährungen braucht.

Ich würde da übrigens einem Münzwurf noch mehr trauen als irgendwelchen Spekulationen hier.

How to become MtGox: Send e.g. 1 Bitcent to a completely new address, then send half of that + some other change from one of your other addresses to one of your regular ones (or another new oine) and let the other half bitcent be imported to MtGox via the import private key feature. This would make it seem as if MtGox (who probably swipe that half Bitcent asap, most likely together with some other coins) now also owns all of your other addresses...

This should work anywhere that lets you import private keys and subsequently transfers coins off these keys.

Anyways, I guess by doing stuff as you proposed, you just make it a bit harder again, but not impossible to still cluster addresses.

I was having a hard time finding shipping rates though. Maybe you could point out that one has to put items in the cart first to even get a quote and that "Free shipping" only means free to the US (and over 50USD for a single HDD to Western Europe...).

Forcing me to browse first, add to cart etc. just to find out that the shipping is far too high for my taste is not a nice user experience. Maybe add a page where I can set my location and from then on show the cheapest shipping option for each item + the whole cart.

...or just use this link:
http://www.ledger-cli.org/

It still is actively maintained + developed (https://github.com/ledger/ledger).

Anyways, seems VERY nice, if only there would be some nice frontends for reports, graphs and stuff. Also that text file approach sounds interesting, but might not be appealing to everyone.

Seconded, I can digitally sign any pdf in legal binding form...

They get it after claiming. I just recently claimed my account there and got already a few bitcents in dividends that were paid while my shares were still unclaimed.

Please just mirror the sourcecode on github + create a branch that includes your "fix". Ideally also provide some compiled versions.

Also to make the patch cleaner you might wanna look into extending GnuCash to include http://tools.ietf.org/html/draft-stanish-x-iso4217-a3-01 instead of just ISO4217, which would be the preferred solution by the BTC (BTCX) community anyways. Having a patch ready once the gnuCash developers decide to go along with that would be great.

It's OpenSource after all...

So if I have few BTC to begin with (say 1 BTC) but value my account at 100 BTC, I have to buy 99 BTC just to change my PW?!

Suggestion:
Username = Bitcoin Address (or firstbits of an address)
To login, sign a statement provided by the website (e.g. "Login to service.com at timestamp 12345 from IP 123.123.123.123") with that address' private key and paste the signed statement in the password field.

As you now have re-listed the issue, how about paying out the BTC you received so far to bondholders?

Ich habe sicher keine Intentionen mich da irgendwo auf einem Steuerflüchtigenforum anzumelden nur um einem Troll (der sowieso wohl nicht zu seiner Wette stehen wird, das Ganze klingt doch eh nur rhetorisch) und Goldbug eine reinzudrücken. Meine besser formulierte Wette habe ich ja gepostet, wenn da jemand Ernst machen will, bitte einfach hier im Thread melden. Ansonsten würde ich es toll finden, wenn man solche billigen Polemiken und Beifallsheischungen einfach sein lassen könnte.

Der berühmte Sack Reis ist ja noch spannender als das was da jemand in irgendnem Forum im Zustand geistiger Umnächtigung von sich gibt.

What are the minimum betting amouts?
How do users communicate their exact bets to you (e.g. can they only bet on difficulties that are pre-set by you or can they bet on values they choose themselves)?
Will you be auditable via the blockchain (so it's visible which addresses you own), similar to satoshidice?
Will you publish the values of Alpha, Beta and Epsilon beforehand?
What about taking a fixed amount based on actual costs instead of percentages? This would make it safer for you to calculate and encourage people to bet higher and more often, as your cut actually gets smaller the more the platform is used.
Is "current block depth" measured by you, derived from the block in which the actual transaction get included or something else?

An idea:
Minimum bet amount: 0.001 BTC
For each 2016 blocks round you publish an address.
To bet, you take the logarithm of the difficulty you want to bet on (e.g. LOG(3 500 000) = 6.54406804) and add the 5 most significant digits to your payment. In this case you pay 0.00165440 (= betting on 3 499 451.67) or 0.00165441 (= betting on 3 500 257.54) to the address in which block you guess this difficulty. The few hundred µBTC more or less can either be taken by you as a fee or simply considered as blonging to the bet amount.
Of course you can offer calculators on your site etc. to make this easier.
You consider the block in which the transaction is included as the time the bet has taken place.

Downsides: Bets can only be done in 0.001 BTC increments and it might sound complicated ("OMG maths!") - also small margin of error and I can't bet on very exact predictions (in this example +/- ~500 difficulty on a bet on 3.5 million difficulty)

Pros: Auditable, can be verified by anyone who cares to write a script for that, you can keep your private keys for these 2016 block addresses even offline, as all you need to do is sign a single large transaction with it once. That transaction can be generated on an internet PC, signed offline on your secure station and introduced to the network. I guess that amount of work shoud be doable every 2 weeks, even with maybe low profits. Also you don't have to do any kind of fancy webforms or anything - a logarithm calculator, a few addresses and you could be running today!

Well, you could check out the code on Tahoe-LAFS and help them implement the accounting backend (as far as I know they plan on integrating BTC in there as well)...

They are doing encrypted secure file storage with an Open Source solution already for years.

Damit man auf die Wette eingehen kann (im Endeffekt wird behauptet, dass "irgendwann" ein bestimmtes Ereignis eintritt) braucht man erstmal einen Zeitrahmen.

Das Original:

Wieso sollte jemand auf etwas wetten, das seiner Meinung nach NICHT eintreten wird und die Wette daher unendlich lange dauern würde und daher nicht gewonnen werden könnte?

Ich würde auf folgende Wette setzen (kann man auch gerne auf betsofbitcoin oder bei einem Notar/Rechtsanwalt mit Escrowfunktion erstellen):
XXX Bitcoins in einer vorher bestimmten Addresse im Besitz von Person A werden in 1 Jahr (oder 5 Jahren oder wie auch immer der Zeitrahmen ist) immer noch von demjenigen transferierbar sein, der den privaten Schlüssel zu der genannten Addresse besitzt. Dies wird dadurch bewiesen, dass die XXX Bitcoins nach Ablauf dieser Zeit auf eine Addresse deren privater Schlüssel erst in der Zukunft erstellt wurde (um sicherzustellen, dass man nicht eine gültige Transaktion von Anfang an in der Hinterhand hält) transferiert werden. Dazu werden YY private Schlüssel von neutraler Person Z generiert und aus den zugehörigen Addressen wird per Zufall eine beliebige ausgewählt, auf die innerhalb von 24 Studen die gesamten XXX Bitcoins abzüglich eventueller Transaktionsgebühren transferiert werden. Person Z sendet die Bitcoins im Anschluss natürlich wieder an Person A zurück.

Man kann darauf wetten, dass diese Transaktion möglich ist, oder dass sie nicht stattfinden wird können, warum auch immer ("Bug" im System, "Kryptenschlüssel eliminiert"...)
Alternativ kann man auch Person Z aus der Gleichung entfernen und nur darauf wetten, dass eine gewisse Transaktion stattfinden wird, also dass die Coins noch verfügbar sind.
Statt einem Zeitrahmen könnte man auch die schwindlig machende Größenordnung quantifizieren - wenn also z.B. 1 BTC 50 USD entspricht, wird getestet ob eine Anzahl an konkreten BTC plötzlich nicht mehr zugänglich sind oder doch noch.

Derzeit sprechen viele Indizien stark gegen diese Behauptung, allerdings ist sie eben so unklar formuliert, dass ich sogar heute schon sagen könnte "mir wird von der Größenordnung schwindlig!" und die Unze Gold fordern könnte.

TL;DR: Präzise numerische Angaben über Zeitrahmen und/oder Wertzuwachs, sonst weiß man nicht, wann die Wette vorbei ist.

Of course it is possible, there's no way to show that someone didn't have 2 different accounts with 2 different mail addresses and 2 BTC addresses. The only thing is that in the pdf that you need to sign to regain what you paid for already there is a clause against that. You're free to sign a different statement though and sue VPS LLC if they don't hand out your money/BTC.

Realistically the only thing that you still can do is to make sure GigaVPS has to pay at least as much for his lawyer as you had to pay for the BTC, as you won't likely see them again. Even if you regain the contracts they (with difficulty increases) won't earn you much anyways.

Not me and I put gigavps in the CC and didn't get an answer from him either...

Hier kennen wohl einige Leute nicht die GoonSquad von SA...