But if there were actual fake IDs or ID theft involved in this case, wouldn't Karpelès make it public? Wouldn't he say "I know which Gox accounts were linked to the theft but those users used fake IDs"?

That question in the Subject line is a rethoric question. The answer is that Karpelès still has got the coins.

I just found a comment on a blog which hints that since the coins which were stolen from Gox were stolen through normal withdrawal transactions, it should be feasible to track the transactions to the bad guys who stole the money:

Anonymous
March 26, 2014 - 00:20

“There is another issue that just came up in my mind.

Gox should be able to find the transactions in the blockchain where the coins went lost. These TX went to Bitcoin addresses. So Gox knows the Bitcoin addresses of all of the scammers. Now, why did Gox send funds to these addresses? They sent the funds because some users told them to do withdrawal transactions. I’m pretty sure that Gox is still in posession of their database where any Bitcoin address that was ever used for withdrawal can be linked to a Gox account. So Gox knows which Gox accounts were used for this scam. Mt. Gox is in posession of identity information for most (albeit not all) Gox users. So Gox has the names, addresses, ID card copies, and proofs of residence of many of the scammers which were involved in this exchange robbery. They know who has stolen the money.

But why don’t they try to recover the money from the thieves? I mean, they could sue them / freeze their accounts / report them to the police / etc.

But they aren’t even trying to do it. They just sit there and accept the ‘reality’ that the money is gone.

Honi soit qui mal y pense.”

(Edit: Btw, the last sentence is an idiom which means something like “smart are those who think that something evil is going on here”)

Keep in mind that it doesn't cost them much money. They would just have to run a server that checks and signs some transactions, so we don't need a large incentive. For instance, a merchant or exchange operator could offer this service for free because it protects themselves from double-spends. Given that double-spends have already happened on the network, this should be a significant incentive.

Alternatively, auditors could also charge for their service. Fees wouldn't have to be high. Given that the auditor is only doing very little work, fees would be no more than ~ €0.10 per commenced 1000 tx. This fee would be payed in advance because including a seperate output for that purpose in each tx would be too expensive.

I raised the very same issue in this thread: https://bitcointalk.org/index.php?topic=192918.new

Yes, there is. The tx which was broadcasted first is legitimate and any other transaction that is broadcasted later is non-legitimate.


There are use cases where you don't want to wait for confirmations.

I've given some thoughts about what nasty things an evil miner could do, and I think I found two problems that I'd like to share:

First of all, a miner is supposed to follow the following rules when including transactions (ordered by priority in descending order):
1) In case of a double-spending attack, the oldest tx is the legitimate one. Only include the legitimate tx in the block.
2) Include as many tx in the block as you can.
3) Maximize your profits by prefering tx with higher fees over tx with lower fees.

And here's the problem. Miners should follow rules 1 and 2 even if they could make more money by braking them. I do think that eventually, miners will show up who have different priorities.

First, 0-confirmation double spendings aren't new. However, I'm afraid that eventually, some rogue miners will show up and create a market for double-spending attacks. I mean, solo miners who try to put wrong transactions into the blockchain are one thing. Now imagine what would happen if several rogue miners got together and exchanged wrong transactions with each other. It would combine their hashrate and increase their profits because now, they wouldn't have to mine blocks for their rogue confirmations themselves, they can also buy wrong confirmations from other miners. This would be dangerous for the network as a whole because it would decrease the costs of confirming a non-legitimate transaction.

The second issue is that miners could artificially slow down transaction confirmation. The confirmation process is supposed to be a competitive market. Supply is limited by the maximum block size; Miners will always prefer those transactions which include the highest tx fees, however they will also try to include as many tx as possible in order to maximize their profits. However - there's a weakness in the system: Miners can reduce supply artificially by mining smaller blocks. This way, users would have to pay higher transaction fees in order to have their transactions cleared. A small transaction fee increase may appear acceptable. And we might hope that this guy doesn't have enough market power to reduce network-wide supply to the point where it increases his profits. However, there are cases where a user doesn't want to wait for the block after the block after the next block that will finally include his transaction; Instead, the user may want the transaction to clear NOW. And now, let's look where we can buy "transaction inclusion in the next block". We can buy that service only from exactly ONE miner. We don't know who's going to mine the next block before it's happened and each time it's someone else. Yet, there is always only one miner who is going to mine the next block. This situation is called a monopoly. Rogue miners could exploit it - they could require excessive transaction fees from those users who want to get their tx confirmed ASAP. When a user refuses to pay the inflated tx fee, the tx would have to wait until a sensible miner creates a block.

The combination of both scenarios is another problem. If there are too many miners around who refuse to include legitimate tx we have a higher chance that a non-legitimate tx might make it into the blockchain because now there are SEVERAL miners who have the opportunity to include wrong transactions.

Bottom line: At any time, there is only one miner who is going to create the next block. This miner is a central authority which has the (temporary) monopoly on tx inclusion and the authority to make almost-final decisions about double-spending transactions. Even though the powers of this central authority are passed around all the time, it is still an issue in the above scenarios.

As a solution, I think that we need double-spending safeguards that relieve users from the need to rely on the moral integrity of a particular miner.

For a beneficiary (merchant/exchange/whatever), the safest thing to do in case of a fork would be to require that transactions clear in both blockchains until it is clear which blockchain wins; However, this gets a bit difficult if either blockchain happens to be slow.

However, I think that it's a gross negligence not to watch out for any double-spending attacks. I think that the risk of double-spending attacks could be mitigated substantially if any client which sees a double-spending attack would warn the beneficiary. This would have to be done outside the normal broadcasting system because 1) nobody exept the beneficiary needs to receive the warning - so we don't need to flood anybody's network connection with this info. 2) Each client is supposed to bury the wrong transaction by not rebroadcasting it. REbroadcasting it anyway could encourage miners to include it in their blocks which is what we want to avoid.

0.22 of a penny is £0.0022.

You can't pay someone a fraction of a penny. Debts that involve fractions of the smallest currency are usually rounded to full multiples of the smallest unit. E. g. if your phone company charges 1.79 ct. for a one-minute call, it would be rounded to 2.00 cents.

I think there's a difference between banks and shops. If you actually happen to sit on a large amount of coins (e. g. because you're running a grocery store and all customers pay with coins), then the bank is supposed to be the place where you deposit them. Some banks also encourage their retail customers to deposit the content of their piggy bank to their savings account. Naturally, they don't like to count that by hand which is why large branches often have counting machines for that purpose. The small branches, however, often don't have counting machines so they have to count coins by hand.

However, in most jurisdictions, legal tender doesn't mean that people have to accept absolutely anything that is legal tender. For example, vending machines never accept 1ct and 2ct coins; Given that all vending machines work like that, I would doubt that this practise would be declared illegal in court. However, in Finland, stores have to accept 1 ct and 2 ct coins even though such small coins are not used in Finland. Most people use to throw these coins into the trash because they don't know what to do with them; The postal service however, uses to ship their 1 ct and 2 ct coins to Germany in order to get rid of them.

By the way, you don't have to use cash in order to piss people off. I recall that there was a case over here in Germany where someone was angry with his lawyer (probably because he lost a case). So he chose to pay his lawyer with ~20 000 wire transfers, each amounting to 1 cent. The lawyer was charged €2.50 for each of these transactions. (The client probably had an account with unlimited free wire transfers.)  Now the lawyer reacted to this payment by sueing his former client. He won the case; the court decided that what the client did was an "immoral damnification". He was ordered to compensate the transaction fees he had caused, which he also did. He refrained from splitting up that transaction as well.

YOu're right about that as long as the smartcard behaves. Did you look at the approach that I suggested in the other thread? I'm proposing an approach that removes the 3rd party out of their position of power without requiring a smartcard.

You may also want to look at this thread [1] where I suggested to prevent double-spending by requiring several (at least two) signatures on a tranaction. The first would be from the paying party, the others would be from 3rd parties who would just confirm that the transaction is not part of a double-spending scam.

[1] https://bitcointalk.org/index.php?topic=189697.msg196627

Here in Germany, we already got an electronic payment system that uses exactly this approach.

You can move funds from your bank account to your Geldkarte. The Geldkarte is a smart card to store money (Euros) on. When you add funds, this transaction will be stored on your Geldkarte. Then, you can go to an OFFLINE vending machine to spend the money. Just insert the card, push a button, wait a second while the Geldkarte creates and signs a transaction that transfers money to the merchant's card. When that's done, you can leave with your product and remove your card. The merchant would later take their merchant's card and move the funds to their bank account.

This system is protected against double-spending by not allowing the user to read the keys from their smart card. So basically, the merchant has to trust the customer's bank not to issue cards that can be used for double-spending. In addittion to that, there are a few more safeguards:
- all cards will expire eventually. If someone manages to hack one card, they can only double-spend with it until it expires.
- the Federal Central Bank maintains shadow accounts for all cards in order to detect any double-spending attempts, even though they should be impossible.
- Funds cannot move freely within the system. They can move from a bank account (or cash) to a Geldkarte. From there, they can only be moved to a merchant's card and from the merchant's card, they can only go to the merchant's bank account. Instead of spending funds, users can also request a refund.

Even though pretty close to everybody here in Germany has a Geldkarte, only few people actually use this system because:
- Nobody bothers to move funds to their Geldkarte
- There are always other payment methods available
- There are only few places that accept Geldkarte payments; Even though it would be possible to accept the Geldkarte in stores and on web sites (card reader and some software required), I have only seen vending machines to accept them.

The Geldkarte has a pretty clear pro - it prevents double-spending without requiring an internet connection. Yet most merchants don't accept it. A large number of merchants uses to process payments by any other payment method, most notably "wild direct debit" - i. e. you authorize your POS payment by signature and it will be processed as a chargeback-prone card-not-present direct debit.

Note that those mechants whom I am talking about always use payment processors and card terminals that would support an online balance check as well as chip&pin. However, they would have to pay surcharges for that which are sometimes just considered to be a bit too expensive; It's cheaper for them to risk a chargeback and transfer the matter to a debt-collection agency when neccessary.

There are also merchants who make a differnece between small and large transactions - small  ones are processed by wild direct debit (it's called "wild" because all banks dislike this payment method because they can't make much money from it - yet all banks offer it to their business customers) while large ones may be processed with chip&pin.

I think you misread what I wrote. I suggested that my funds would sit a special address from which they could only be spent with signatures from all (or at least the majority) of my "semi-trusted 3rd parties". If one of the "semi-trusted 3rd parties" refused to sign my transaction, every node in the network would reject it. No hashing power needed.

This feature would already be feasible today without changing the existing protocol. However, it puts the user at the risk to lose their coins if one of the "semi-trusted 3rd parties" just refuses their signature, disappears or has trouble with their internet connection. Keep in mind that any of my ST3P can block my transactions, so the chance that my coins get frozen because of a dead ST3P is higher than the chance that a particular e-wallet service disappears. In order to mitigate this risk, we would need the option to perform an exit transaction and that would require a change to the protocol.

Btw, I don't really like the term "semi-trusted 3rd party". Does someone have a suggestion for a synonym?

The client will try to exchange blocks and transactions with other clients.

Well, in fact your client doesn't regard a bare Genesis block as a complete blockchain - it says "out of sync" which means that part of the chain is missing.

No, not really. Every client developer knows which Genesis block is the right Genesis block and this right Genesis block is hardcoded into all clients. No confirmations or anything are neccessary - everybody knows which Genesis block is right and which Genesis block is wrong. If someone comes up with a different Genesis block, they can build their own blockchain and their own network on top of it but a normal Bitcoin client will ignore that.

I think I got yet another idea how double-spending attacks can be discouraged. Previous ideas included green addresses and pre-paid accounts. Both of these approaches have drawbacks because they require the user to trust either the beneficiary or the 3rd party and funds still need to be sent to some kind of pre-paid account or e-wallet service at least 6 blocks in advance. And you always have to know whom you want to send money to during the next 6 blocks because each beneficiary can come up with different requirements - some want a Mt. Gox green address, another may have their own prepaid system. In addition to that, you always need to trust the guy who has your money.

Now I think I got an idea: The bitcoin protocol already allows for funds to be owned by several keys (for 2-out-of-3 agreements and similar stuff). This would allow us to mark an output as "can only be spent if A, B, C, D, E and F agree". In this case, A would be the owner of the output and B, C, D, E and F would be semi-trusted third parties. Now if I wanted to spend my output, I would first sign the transaction and then, I would go to B, C, D, E and F. They would check whether I have signed the transaction and then, they would check whether I'm trying to perform a double-spending attack (they would just have to check whether they have already signed a conflicting transaction). If there's no problem, I'd get my 5 signatures and could start broadcasting my transaction. The beneficiary can now see that I could only conduct a double-spending attack with approval from B, C, D, E and F; He just needs to trust one of these 5 3rd parties. If it turns out that some merchants out there don't trust any of my 3rd parties but instead only trust in G or H, I could add those to my list of semi-trusted parties as well.

Now there's just one small issue - what happens if one of the semi-trusted 3rd parties refuses to approve my transactions, for any non-legitimate reason? Then I'll be unable to access my funds. In fact, nobody can access them. In order to solve this, we would need a feature that I would call an "exit transaction". An exit transaction is a way to remove the above restrictions from an output. However, this kind of feature obviously needs some kind of protection against abuse, and I got a simple idea how we could implement such a protection: We just need to require that A (the owner of the funds) announces their intent to perform an exit transaction some time (let's say ~100 blocks) in advance. This announcement would have to be made in the form of a special transaction that would be put into the blockchain. Now, A (the owner of the output) would have to wait 100 blocks. After these 100 blocks he would be allowed to perform his exit transaction without approval from his semi-trusted 3rd parties. However, during these 100 blocks, regular transactions would still be allowed to clear as usual, so a regularly signed transaction would still be allowed to clear. Obviously, merchants should refrain from trusting any transaction involving the output in question after an exit transaction was announced. However, if an announcement transaction is broadcasted just after they received a payment and the customer is already gone, they don't have to fear anything because the legitimate transaction would have plenty of time to clear before the bad exit transaction would be allowed to go into the blockchain.



I'm a bit worried that this approach might cause transactions to grow significantly in size; But apart from that, what do you think? Would this approach work?

The chance that someone manages to guess your private key is close to zero. It is more likely that 4 definite people get independently struck by lightning tomorrow, so there's not really a problem here.

And if we assume that the issue you're seeing here was an actual issue (in fact it isn't), then your idea would be a non-solution because an attacker could still try to guess your password just as he can try to guess your key.

I think that we don't need yet another IdP and OpenID in particular is a bad idea because it's too confusing. People just can't think of a URL as their identity.

What about implementing Mozilla Persona ( http://persona.org/ ) as a relying party? I think it's the SSO system of the future.

Das ist eine ganz schlechte Idee, weil Nachnamesendungen bei der DPAG eine ziemlich unsichere Sache sind. Es kommt oft zu Sendungsverlusten; Manchmal werden die Sendungen ausgeliefert, ohne dass das Geld kassiert wird. Manchmal wird das Geld auch kassiert, bleibt aber unterwegs irgendwo stecken. Dazu kommt noch, dass man die Nachname im Inlandsverkehr nicht mit Einschreiben kombinieren darf. Bei Sendungsverlusten hat man somit keinen Nachweis, dass man die Sendung jemals abgeschickt hat.

Hinzu kommt, dass die Schutzfunktion, die die Nachname bieten soll ad absurdum geführt wird, wenn man dieses Verfahren mit einem Treuhänder kombiniert. Denn ein leeres Bitcoinwallet ist wertlos. Stattdessen könnte man auch eine leere Postkarte verschicken und den Empfänger das Papierwallet selber erstellen lassen.

Wenn einer Angst davor hat, sein Bankkonto zu benutzen (oder er gar keines hat), dann kann er das Geld immernoch per Zahlschein bei der Bank direkt auf das Empfängerkonto einzahlen. Die Post macht ja mit dem Nachnamebetrag auch nichts wesentlich anderes.

Kurz: Vergiss es, es macht keinen Sinn. (Bitte nicht persönlich nehmen)

In some way yes, but the rate will continue to grow.

I wouldn't care about people laughing at me for believing in bitcoins because in the end it's going to be the early adopters who will be rich.

Es gibt legitime Gründe dafür, es doch zu tun - nämlich wenn man den Gutschein schon hat und ihn loswerden will.