Topic: Double-Spending effects with accounts (Read 1069 times)

i would never accept 0 conf tx's.
to rephrase this simple:
account balance is based on 2 things -> tx's which can be unrolled due to blockchain fork/sync/resync/orphaning and move operation which are stored in the wallet and wont be unrolled.
therefore with the example @ #1 if i would move 0.5 BTC away from this account after a double spend attack the account should have a balance of -0.5.
so if a account has 1k tx's, everytime i request "getbalance account" all 1k tx's will be checked for existence and nothing will be cached/similiar? i hope it does check every tx and dosnt cache anything (like everything past 1k blocks).

thanks for your help

Yes, unconfirmed transactions are stored in a memory pool.  And yes, when a transaction ends up in a block, it is removed from the memory pool.  The block contains the transactions, so in a sense, relaying the block relays the transactions, but they aren't sent as transactions any more.

If the block is orphaned, the transactions in it will be added to the memory pool , and then the new chain will remove some fraction of them right back out.  I'm actually not sure if the node will then try to relay the transactions it has in memory.  It doesn't matter in the long run though, because each node checks its own wallet, and will try now and then to resend anything that it thinks it has spent, but hasn't seen yet in a block.  So, the sender is ultimately responsible for getting their stuff out, and if any other nodes help, that is nice, but not necessary.  If a node goes offline, eventually their stuff will expire.

The actual code may optimize things a bit by building intermediate sets or whatever, but you have the net effect right.  Any transactions that were valid before the reorg and are still valid after the reorg, but were not included in the new blocks, will still be valid, and should end up in the memory pool.  But it turns out that it would be just as valid to throw them away, because the original node will resend them.

move does not involve the network at all, it just creates entries in the internal ledger.  As such, they are not subject to rollback.

This could be troublesome for you if you are using move in response to unconfirmed, or barely-confirmed, transactions.  But it should be fine to use it for your own transactions.

Example.  I get a bunch of small payments from p2pool, but want to de-clutter my wallet.  So, I use the raw API to gather a bunch of them up and send them back to their own address.  But I use an account to keep track of my p2pool earnings, and now the system thinks I've just been paid again, so I use move to reduce my p2pool account by the same amount as the transaction that I just sent myself.  This is safe because I know that I'm not going to double spend against myself.

thanks, so im asuming that bitcoind is matching tx's to an account and calculates the sum of it for the balance, what happens if i used move to transfer part of the funds? these things are stored in the wallet.dat therefor these shouldnt be invalidated right?
is there some documentation about this?

If I bring up a new node, I assume that all the transactions that are not yet in a block are relayed to my node after it connects to a peer.  Somehow that peer knows about these transactions even though they are not yet in a block.  I assume this is because the peer holds transactions that it hears about in its memory pool.  Then if a block comes along that has these transactions in it, there is no longer a need to relay the transactions from the memory pool because they can be found in the relayed blockchain.  Does this mean that they are removed from the memory pool and no longer relayed to new nodes?

Now if that block is orphaned, and one of those valid (not double-spent) transactions from that orphaned block are not included in the new blockchain, how do new nodes learn about the transaction?

I've assumed that each node loads all the transactions from the orphaned blocks back into their memory pool and then compares those transactions against the blocks in the new blockchain to see which to remove (leaving behind in the memory pool all the transactions that were in the orphaned block but not in the new blockchain).  Is this an accurate view of what happens?

The account balance stuff is really just a sum of individual entries.  If the node reorganizes its chain, it rolls back everything in the removed fork, and then applies whatever it finds in the new fork.  This happens pretty often actually, but has no net effect, because for the most part, the two branches involved are very similar.  In a double spend, one of the removed parts will not be found in the new branch, and will not come back.

In short, the numbers are always correct relative to the node's current idea of what the "best chain" is.  And yes, it has been tested extensively, both on the testnet, and in reality.

So am I understanding you correctly if I assume that you are asking what happens to all the transactions in orphaned blocks?

I've always assumed that when node sees a transaction in a block that it removes the transaction from its own memory pool.  I've also assumed that if a block becomes orphaned the node places any transactions from the orphaned block that don't exist in the new blockchain back into the memory pool until they show up in another block.

I haven't bothered to look at the code yet to see how this happens, because whatever it is doing clearly works.

Lets say i transfer 1BTC to 1PlsTryToDoubleSpend...
according to the daemon the account with this address has now 1BTC. lets asume someone is going to fork the chain and publishes the longer chain later for double-spending, will the balance of this account be 0BTC or 1BTC?
I know this wont happen still i would like to know about it.
Was this already tested @ testnet for example?

TL;DR:
How are accounts affected to a Double-Spend attack (forking the chain and if the chain is longer, publishing it)?