There is a "move" command in Bitcoin, Litecoin, Dash etc. which lets you move balances between wallets in your node without paying a transaction fee.

I wonder if there is a similar command in geth? I'm currently using geth and transferring balances between wallets with eth.sendTransaction command which costs me extra tx fee.

  • Does this have a production reason or a debug reason?
    – JBrouwer
    Commented Apr 1, 2018 at 20:37
  • production reason Commented Apr 2, 2018 at 14:58

1 Answer 1


TL;DR Bitcoin's "move" command is an off-chain operation; this is why it can be done for free. It is a logical regrouping of address balances. An account in Bitcoin is comprised of one or more addresses. A send command in Bitcoin and Ethereum is an on-chain operation that actually changes the balances of addresses.

Based on my understanding, the "move" command in Bitcoin and friends probably operates quite differently than you might think. (Simplifying a bit) in Bitcoin, there is a concept of an "address" which is the same as an address in Ethereum: addresses are alphanumeric identifiers that have amounts of bitcoin (or ether) associated with them. In Bitcoin, you send bitcoin to an address, but the clients I'm familiar with generally let you interact with "accounts" (I think it's the same thing as what you mean by "wallet"). An account is a collection of addresses, each of which may contain bitcoin. Unlike Ethereum, when you send bitcoin, you must spend ALL of the bitcoin that was received in a particular transaction. Thus, to preserve pseudonymity, it is common to send the change back to a change address rather than the originating address. This makes it harder to determine how much was sent. For example:

  • Address A (owned by Alice) receives 3 bitcoin in transaction TX1.
  • Address A (owned by Alice) receives 5 bitcoin in transaction TX2.
  • Alice wants to send 1 bitcoin to Bob.
  • Alice signs a transaction, TX3, whereby TX1 is spent in the following way:
    • 1 bitcoin sent to address B (owned by Bob).
    • 2 bitcoin sent to address C (owned by Alice).
  • Alice wants to send 2.5 bitcoin to Charles.
  • Alice signs a transaction, TX4, whereby TX2 is spent in the following way:
    • 2.5 bitcoin sent to address D (owned by Charles)
    • 2.5 bitcoin sent to address E (owned by Alice).

Now, Alice controls keys for the following addresses: A, C, and E. They contain 0, 2, and 2.5 bitcoins, respectively. Now, Alice can decide to create a fake identity, Alicerino. She can assign address E to this new account for Alicerino by using "move" and remove the private keys for E from the normal Alice account. Previously, if Alice wanted to send more than 2.5 bitcoins to someone, her wallet could take bitcoins from addresses C or E, but now it won't. For example, if Alice had NOT "move"d the bitcoins, she could send 3 bitcoins to Daryl like this:

  • Alice signs a transaction, TX5, whereby the outputs TX1-C and TX2-E are spent in the following way:
    • 3 bitcoin sent to address F (owned by Daryl)
    • 2 bitcoin sent to address G (owned by Alice).

Notice that all of this happens off-chain. Ethereum doesn't allow merging of address balances like that, so there is no equivalent. If you need to combine two or more address balances to make up a particular amount in Ethereum, the receiving party needs to know that the multiple addresses should be treated as coming from the same person and/or the amount from one or more addresses is sent to one address prior to performing the transaction.

A weird fruit-based analogy: If you have a basket of 10 oranges, you could say to your friend, "feel free to eat any orange with a sticker on it." This is equivalent to having 10 addresses in Bitcoin with a bitcoin each; your "friend" here is a Bitcoin wallet. The oranges with a sticker are account A and the ones without are account B. Thus, multiple addresses may belong to each account. But you can freely change whether or not there is a sticker on the fruit. At least until someone eats the fruit (your bitcoin is spent).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.