A sybil attack would be just me selling to myself a 1000 times (you could also call it the "Huobi" attack... ) from a couple different accounts... All of these trades would be (of course, there is no need to even actually transact funds!) successful ones.

I am in Europe and I would not trust that SEPA transfers are irreversible at all. There are cases every few weeks in the German subforum that support this claim. Even if they are irreversible, your bank account still will get locked up sooner or later as soon as someone sends you money from a phished account.

You just describe NashX and as I already said, there are strategies where Bob can benefit from Alice loosing money, even if it costs him a bit as well.

Once the collateral gets higher by the way, there is an easy extortion attack: freeze both collaterals + Alice's coins she sells, don't send money but agree to release the collaterals at least if she claims to have received money. As soon as the collateral become worth more than what she would have gained from selling the coin back in the days, she is acting economically rational to agree to that deal.

This only works if the price for BTC is stable.

At the time of the trade, 1 BTC is 1000 USD.
Alice buys 1 BTC, freezes 0.1 BTC, sends 1k USD honestly.
Bob sells 1 BTC, freezes 1.1 BTC, receives 1k USD but never reports on it.

Once these 1.1 BTC are worth LESS than 1k USD, Bob was smart.

Staying honest when selling with this scheme just depends on how low you think the price would go.
Only if he believes the price won't tank more than 2-fold until he gets the money. Also he has now a much higher risk that someone locks up 2 BTC to lock up 3 of his. Potentially forever.

Would you sell me 1 BTC right now via bank transfer if we both need to lock up 50 BTC for that?

Which economically rational person buys unbacked digital assets?

Anyways, if you for example have stolen money or Bitcoins, you don't need to be economically rational. Also paying a price for hurting your competition can be economically rational.

It leaks private data (cash in mail: mail address, bank transfer: bank account data) all over the place. I described one problem (stolen bank data which will lead to later reversed USD transactions) already, also there can be indefinite lock-ins, the extra funds at stake (in your example 10%) can lead to people implicitly taking a short/long position, it requires trust to begin with (who wants to trade with a newbie in your system?), both traders need to be online and do manual tasks outside of the system...

I mean, feel free to try this out in practice, it's not even hard to do - just post an offer in this forum for the mean time, put some funds on the table and get trading. It took less than 2 weeks each for 2 different new Ripple gateways, until they had a few 1000 USD bank transfers reversed each. Maybe you can beat them to it?

No you can't.

We both put up 50 BTC, I send you a couple dozen self-printed 500€ bills and claim the post man switched them. Heck, I can even take pictures and whatever you want of me putting in real money beforehand. If you want to, I'll even make a video, uncul, of me stuffing 100% real money in an envelope, sealing it, writing your name on it and handing it in at the post office, no problem. You'll still receive ony fake money and after some time our 50 BTC each will either have to be returned or destroyed. I still have proof and go to court, also your reputation on that exchange is destroyed.

Also I could send real money. With the GPS tracker from the last bank robbery still inside (or not, doesn't really matter if the serial numbers are tracked).

It already exists on nashx, localbitcoins and bitcoins.de for years.

This scheme won't work, is exploitable (buy BTC from stolen bank accounts and screw Bob), does require trusting banks and has loopholes all over the place.

All you did is describing bitcoins.de but instead of saying "they go to a website" you said "they exchange data via BitMessage" and doing multisig transactions instead of escrowing with a neutral third party.

Might not be the smartest idea to give your mail address to strangers if you trade a couple dozen BTC... also cash-in-mail can and will get lost - how does Bob proof to Alice he got just an envelope full of copied dollar bills and how dies Alice proof to Bob that she actually put the money in there?

The bank transfer(s) can be reversed after the BTC are released. Alice Will steal Eve's bank data, send 1k USD to Bob, pocket the BTC and then Eve gets Bob in trouble. This happens often enough on both localbitcoins and bitcoins.de already right now (since that's the exact same system these are operating under).

The bank transfer network is the third party in that scheme and it sucks compared to Ripple for example, since transactions between banks are reversible. It would only work with cash-in-mail and even then you need to trust the postal services.

Also if BTC prices fall more than 10% until the BTC are sold, Bob is better off never releasing the coins. Using this system is like shorting BTC on reversible bank transfers no less. Good luck with that.

This "decentralized trading" idea can only work with digital assets (e.g. blinded Bitcoins...), not fiat money. There is no way to "digitalize" a dollar bill without introducing a third parts (called bank, escrower, gateway, exchange...).

Also if you use Bitcoin (or any other BTC based altcoin) you can run ABE, the alternative block explorer to check balances and stuff.

With Ripple you can run a copy of http://www.ripplecharts.com (I haven't seen a "blockexplorer style" site so far, you can use their client for  that though or https://ripple.com/tools/info/) or a lot of their other stuff you can see on their website - code is available at https://github.com/ripple

Lass doch einfach eine Handvoll Föns auf Vollast für 1-2 Tage da drinnen laufen die 2 kW verbrauchen.

Either use Testnet-in-a-box if you want to do mining or you could run Ripple or some other non-mining currency in standalone mode too if you don't want to mine on your expense.

First the source, then the binary.

Any service that uses a smaller hot wallet and bitcoin-qt will soon have a few transactions stuck. They just need to wait for 0.8.7 that stops bitcoind from using unconfirmed transaction hashes as input.

Either you manually rescan from time to time, halt payouts, didn't use bitcoind in the first place or compile and run the proposed patch already now. Since this might be a good time to check your code for the usage of transaction ids anyways, and with sending bitcoins a better safe than sorry approach is recommendable, it looks like a lot of services rather choose to wait for the official patch and look at their own ledgers in the meantime.

TXIDs of unconfirmed transactions can not be trusted to stay the same. <-- We saw what that one did very recently.
If ECDSA requires a RANDOM number, you better make sure you actually use a random one. <-- We had that one too (aka. Android bug).

Any other "long known" wiki articles with things that are likely being overlooked by client implementers or people using the RPC API?
Examples could be some more exotic script types, chain reorg detection, relaying (or not relaying) as well as reporting double-spend attempts, dust spam/collection, some more intricate crypto stuff...

Also bitcoin-qt up to 0.8.6 was/is affected of widespread transaction mutation in the wild...

Just putting the blame on Gox is a bit short sighted, after all a "transaction ID" that is completely random and useless until that transaction is buried a few blocks deep is NOT something implementors actually do expect I guess and while there was some theoretical info on that available, there surely was no big warning like "TXID should never be assumed to stay the same after broadcast!".

All in all, the situation sucks, Gox gets blamed and Bitcoin moves on. Welcome to 2011 2012 2013 2014!

Sooo... wie wird die DEM mit dem Problem der nachträglich veränderbaren Transaktionen umgehen?

I guess the issue is more often that people do send Bitcoins, then get a TXID from bitcoind after submitting the RPC call and store that TXID in case they need to check later if that transaction really went through.

Actually the solution from MtGox is relatively reasonable... there might still be some issues where parts of the actual transaction can be changed and its signature is still valid (as far as I understand it) but in total calling a checksum of the inputs "transaction id" instead of a checksum of the whole signed transaction might be a good thing to have.

All in all, bitcoind should return something that is guaranteed to be able to be found again after submitting a transaction to it, not a TXID that in the end does not mean what people apparently thought it means (known malleability or not).

Good luck with that, let's see if it still has this market cap after 1 year and after giving away (in your case) over 74 billion of your coins for free to a few thousand random people who can trade them too for whatever price they like.