He has no idea. 

Someone sending you money isn't an attack.  It might be annoying but it isn't an attack, otherwise people would attack each other by sending them pennies in the mail.

When you think about it a Bitcoin address is very much like a postal address.  You can't prevent someone from sending you mail, you can't prevent someone from sending you money in the mail, you can't prevent someone from sending bitcoins to an address that is public (and any address you ever received funds from is public).

Honestly I have no idea.  pywallet will delete the tx.  Will bitcoind "accounts" handle that incorrectly?  I don't know.  I don't think anyone knows for sure.  You will find the "accounts" are not a good feature in bitcoind.  It probably should be dropped from the mainline client.

Still if you made a backup RIGHT BEFORE "cleaning up" and it messed things up you just restore the backup you made immediately before doing the "cleanup".

Instead of a loan I will pay you 2BTC for your 2.47 BTC MtGox balance.  Unless it changed transfers between MtGox accounts are still working.

You transfer 2.47 BTC to my MtGox account, I send 2 BTC to a Bitcoin address you provide.

Correct.  If one of the tx is already confirmed you should be able to just delete the other one using pywallet.  If neither tx is confirmed and you delete one it is possible that is the one which ends up confirmed in which case you would need to go back and delete the other transaction.  Also until confirmed it is possible another node may re-relay the transaction you deleted.

Always make a fresh backup before using pywallet, it is a low level tool and very powerful.  It does exactly what you tell it to even if you are doing something "stupid" like deleting funded private keys.  You can loose funds if you make a mistake in pywallet without a backup.

I might not have been clear but I agree.

Bitcoind = equivalent of online banking
Bitcoin accounting (i.e. custom backend) = equivalent of traditional accounting software

Most users will find out eventually they don't want to try and do accounting in the wallet just like you wouldn't want to try to do accounting using online banking.

Well that is just my opinion.  I know Gavin likes it.  For a personal wallet it might be fine but I think you will find that building a custom datalayer which connects to bitcoind to be a better long term solution.  If nothing else it provides better flexibility and scalability.

I guess it is kinda like quickbooks (or other accounting software) vs online banking.  It is far easier to use accounting software and then link to online banking to pull the incoming and outgoing txs then it is to somehow try to use online banking for accounting.

That alone won't help, the issue is that the doubled transaction affects the QT clients "account" recording.  The sender isn't spending unconfirmed change, the tx is being modified (by those trying to prove a point) between the sender and receiver.

One relatively simple option would be to patch the QT client to DELETE unconfirmed mutated transactions (but not traditional double spends) once the confirmed version has one or more confirmations.  If the developer didn't want to delete it, a flag could be added "duplicate" instead which by default would hide the double from transaction display and the "accounts" balance.

An even better patch would be "smart" enough to realize that in a doubled transaction (same inputs, same outputs, different hash) only one copy of the transaction can ever end up confirmed.  Since they both have the same value it would never even consider the second copy.

So
Copy1 receive - unconfirmed balance increased (or decreased for spend)
Copy2 receieved - no change (maybe a special symbol indicating a double and by default doubles aren't even shown

If copy 1 ends up confirmed there is no change other than the confirmed balance increases and unconfirmed balance decreases.
If copy 2 ends up confirmed, copy1 gets the "double" flag, copy2 "double" flag is removed.  The user sees no change in total balance, and the visible tx changes.  The only change is the hash so to the user they simply see the tx hash change.

Sorry about that.  Yeah the built in qt accounts system is well ... garbage for reasons beyond this.   Sorry I assumed when you said "account" you were talking about your own internal accounting.  That would be a problem.

So if you want to use QT built in "accounts" your only option would be to either wait or use a tool like pywallet. The amount of time before they fall from the memory pool is not deterministic, it depends on your nodes resources and the tx volume so it could be hours or weeks.  Obviously some patch for handling this better will be needed but in the interim those are your only options.  As a heads up if you delete the "copy" prior to one of them being confirmed, it probably will come right back, this is because other nodes will still be relaying it.  If you delete the unconfirmed copy AFTER the other one is confirmed the duplicate should not be relayed anymore (as all nodes will see the unconfirmed one as a double spend).

The other option (and in the long run I think you will find this works better) is to scrap the QT "accounts" system and just use the client/wallet as a transaction engine.  In your own database you would track user balances, payments, withdraws, etc, and just query (using RPC API) the client for low level data.  This provides more scalability and flexibility.

For example you can assign a user a deposit address by calling getnewaddress and recording the result in your database linked to the particular user.  When a payment is received at that address you can look it up and know which user to assign it to.  To make detecting transactions and blocks, bitcoind supports the ability to assign a callback function (could be an external program, web call, etc).  It will pass the tx or block id to your system when an inbound tx (or confirmation) or new block is detected.

Yes but there isn't anything magical about 6 confirmations.  I would say the network considers a transaction confirmed once it is confirmed.  How many confirmations you should wait depends on your risk threshold.  For most tx 2 confirmations provides a high level of security.  For some transactions you probably want to wait more than 6.

Satoshi never indicated 6 was some magical barrier it simply was the output of his example on the risk of reversal.  If an attacker has 10% of the network, and you want a less than 0.1% chance of the attacker being able to reverse your transaction you need to wait for 6 confirmations.   However if the attacker has say 20% of the network you would need to wait for 10 confirmations to reduce the attackers chances to 0.3%.

Meni wrote a good paper on the economics of transaction reversing because the attacker has a cost (in terms of potentially lost block rewards) trying to re-org the blockchain.  So the more important factor is what is the VALUE of your transaction.

For example if you assume the attacker has 48% of the network (if they have 51% no amount of confirmations will keep you safe) then you need at least this many confirmations to make the attack non-economical

48%
<= 4 BTC = 1 confirmation
6 BTC = 2 confirmations
8 BTC = 3 confirmation
9 BTC = 4 confirmation
10 BTC = 5 confirmations
12 BTC = 6 confirmations
13 BTC = 7 confirmations
14 BTC = 8 confirmations
15 BTC = 9 confirmations
16 BTC = 10 confirmations

Hopefully we can eventually kill the "6 is good for everyone" way of thinking.
https://bitcoil.co.il/Doublespend.pdf

Many merchants hinder the user experience by demanding an excessive amount of confirmations relative to the transaction risk.  For example someone accepting 0.01 BTC for some game credits shouldn't be demanding 6 confirmations.  The user wants to play right away and making them wait 30-120 minutes just creates the (false) perception that Bitcoin is slow.  Even 1 confirmation provides a higher level of security than other payment methods.

When people are saying the system is uni-direction they are not indicating that one can be a node without any other form of communication.  The "what if they miss a block" kinda misses the larger issue on OBVIOUSLY you need two way communication to transmit transactions.  Having 100% of blocks and no way to spend coins is equally useless.

The point was the SATELLITE link can be unidirectional.  Trying to make a bidirectional sat link is a pipe dream but likely it isn't necessary.

Sat ----- one way data broadcast----------->   [ Node ]  < ------ slower/expensive/limited internet connectivity --------> [ Internet]

Why are you deducting the account based on 0-confirm transactions?
Why are you not either
a) deducting the account based on the actual request
OR
b) deducting the account based on the 1-confirm transactions

There is a tool called pywallet which allows you to manually modify your wallet.  You can permanently corrupt your wallet if you don't understand what you are doing.   However before you start using pywallet maybe you should take a step back and say "am I pulling a MtGox here" by using 0-confirm tx to handle your accounting.

No.

Read up on sybill attacks.  Bitcoin doesn't attempt to identify each node as a unique real world entity.  It doesn't try because in an anonymous network that is (nearly) impossible.  Instead it allows an unlimited number of nodes because doing so gives the attacker no advantage.  It relies on hashing power (proof of work) as a proxy because it is something that can't be faked.

Still even if what you "wanted" was possible you would simply make the coin insanely profitable for those who control botnets.  Some of the largest botnets are in excess of hundred thousand nodes.   So while you are "fairly" mining away with your single computer, a botnet by definition would be mining at 100,000x your throughput while not violating any of the (probably impossible to implement) rules on hashpower per node.

Yes and that is what it is assumed that attackers did.  Of course of that original pair only one could be confirmed so yes to get double paid you would also need to trick MtGox into cutting you another payment.   Of course MtGox client is horribly defective and there were thousands and thousands of legitimate reasons why they had to cut new payments so the attackers requests would hide in a sea of requests created by their incompetence.


Correct, you can not do that.  The inputs, outputs, value of tx, fee paid, recipients, and value to each recipient are immutable.


The OP was a simplified explanation of what MtGox got wrong.  MtGox had a huge laundry list of fails in their client wallet. At minimum (just by observing their "missing" transactions) they
a) tried to spend immature newly mined coins which caused the tx to be dropped (until they matured if Gox was still broadcasting it) by some or all of their peers.
b) tried to make payments which violated the spam rules and thus wouldn't be relayed by some or all of their peers.
c) paid insufficient fees on low priority tx which caused them to not be relayed by some or all of their peers.
d) used non canonical signatures which caused them to not be relayed by some or all of their peers.
e) double spent their own coins which caused the tx to be dropped (correctly) by some or all of their peers.

It is very likely their wallet was deficient in other ways these are just symptoms that I and others have observed by looking at the transactions MtGox created.  As an example, obviously if MtGox is creating a tx which is spending newly mined coins less than 120 blocks from when they were mined we know their wallet is not performing that required check.  How many other deficiencies are in the "Gox Special v0" custom client.  Nobody outside MtGox knows for sure but you should not take this list to be exhaustive.

You assume MtGox is doing daily reconciliation.  Given all the other things they either didn't do, or did wrong why would you assume that.  It is entirely possible they had absolutely no check's and balances in place and the same attacker "double withdrew" dozens or maybe even hundreds of times.  The issue with MtGox generated bad withdraws has been going on for a month.

Bitcoin is cash.  Is cash reversible? No.

However that doesn't mean payment systems can't be built ON TOP OF Bitcoin.

VISA isn't a currency, VISA is a payment system built on top of USD cash system.
_____ isn't a currency, ____ is a (future) payment system built on top of BTC cash system.

If I am understanding your last post correctly they would only add or remove dollars and the dollar balance would be based on the BTC exchange rate.  So if the exchange rate today is $1,000, they deposit $1,000 and have a 1 BTC balance.  Later it rises to $2,000 per BTC so they could withdraw up to $2,000 USD?

It is an interesting idea although my reading of FinCEN overly broad and vague "guidance" on virtual currencies is that would still be considered a MSB.  A startup looking to do that should obtain qualified legal advice though as it could also run afoul of various banking and securities statutes as well.  Ironically it might actually be more regulated than a "normal" Bitcoin ATM.

Why do you need to remove them?
Why are you giving credit to users for 0 confirm txs?

They will drop off automatically when they are deleted from the memory pool to make room for newer transactions.

If you absolutely need to delete them you can use a tool like pywallet to manually remove the tx from your wallet.  Still before you do that you should question why do you need to remove them.  Think of 0-confirm tx as unpaid orders.  Do you need to delete unpaid orders? 

Crash,

Come one man!  I was trying to slghtly humurous upthread and to prove a point.  I gave him an offer to sell to me for $200+ than what he was offering on ebay.  He didn't take it.  Why wouldn't he take it?  He wants less money for the same amount of coins?  He is afraid of getting too rich?

"Nobody sell money for 20% off.  Nobody ... unless they have no intention on paying."

No, they never admitted a problem to begin with.  There website still says that USD withdraws are "delayed" so allow up to two weeks for completion. 

But it will have a different tx id, so they aren't "exactly" the same.  The prior poster is right any subsequent tx would fail.


BTW: Bitcoin doesn't work on the concept of balances it works on the concept of discrete inputs and outputs.  The input of a tx is the output of a prior tx.  You are spending x coins you are spending output X a specific and unique output of which there is no other like it in the bitcoin universe.


So say you have a tx which generates an output A & B where B is the change.
You then create another tx which uses B as the input.

If the first tx is modified it doesn't matter that the outputs have the same VALUE (and are going to the same addreses) they are no longer A & B they are lets say C & D.
Now if this modified tx is the one which makes it into a block then the second tx above which spent B will never confirm.  Why?  Because B no longer exists.