Change address
Where did my coins go? A simplified explanation.
Contents
The problem
If you have 100,500 bytes in wallet address A, and make a payment from it of 20,000 bytes to someone else at address P, this happens:
- 20,000 bytes goes to P
- 500 bytes fee goes to wherever
- 80,000 bytes moves to B, another address in your wallet
- 0 bytes stay in A.
This is normal for cryptos. So if you have 1.005 BTC in wallet address A, and make a payment from it of 0.200 BTC to someone else at address P, this happens:
- 0.200 BTC goes to P
- 0.005 BTC fee goes to wherever
- 0.800 BTC moves to B, another address in your wallet
- 0 BTC stay in A.
These fresh addresses automatically generated by the wallet are called *change addresses*.
Solutions
Usually this wallet behavior doesn't matter. But it does matter when you want to keep funds on a single address, "A" in the above examples, say for the next Byteball airdrop.
The transition bot wants proof that you own the bitcoins at the address you just gave to it. You can either make a small payment to the bitcoin address the bot gives (which will move your bitcoins), or sign a message using the bitcoin address's private key.
Return to sender
- Copy the bitcoin address the bot has confirmed as the linked address
- Use your bitcoin wallet to send all your coins to that address
- Don't spend any bitcoins from that wallet until after the airdrop.
Sign a message
Exactly how to do that is outside the scope of this article. It's easy enough to look up online. Signing a message requires your wallet to be able to do that. Some work, some don't. Known workable ones are:
Hardware wallets
Software wallets
Confirmations
If you have 100,500 coins in A, at the exact moment you send 20,000 to P the remaining 80,000 go into limbo until the A --> B transaction confirms. You can't spend any from B yet because it has zero spendable coins until after the transaction confirms.
If you have other funded addresses in your wallet you can spend those, but if all your funds start on one address then it's "no go" for a while.
Solution
If this is a problem, don't keep all your funds on one address. Maybe have more than one wallet. In Byteball, you can create another one by Main menu > Add wallet. Maybe a "Savings" wallet you use little, and a "Spending" one with far less coins in it to play around with.
More accurately
An example from https://explorer.byteball.org/#H5EZTQE7ABFH27AUDTQFMZIALANK6RBG:
H5EZTQE7ABFH27AUDTQFMZIALANK6RBG
253 bytes
Definition ▶
Unspent ▼
BANbCJ3YozQc7uRzofx7t2ZJAvC0EsCIxpdIm0ynHdM= (28 bytes)
u1xa15o0QGC6MVw1chSaU443NLmOFjoKiTXAVi6z860= (30 bytes)
Nd9VsUTNmfZN2KWPB8RNOkdsYN710kjxNuSXP09731I= (195 bytes)
Here, the 253 bytes balance is composed of three unspent transaction ooutputs (UTXOs) from three previous transactions (28+30+195 = 253).
Ignoring transaction fees, if you were to spend 20 bytes from that address, one of those inputs would be affected as described above while the other two would not. So you could actually make three small unconfirmed transactions before the whole H5EZ... address would become unavailable.
NOTE: This particular address, picked at random from the explorer, is a witness address, so the amounts are tiny compared to normal MB or GB transactions.
Simple solution
From wallet version 2.2, you can send to multiple payees (up to 120) in one transaction. The multiple payees can all be the same address. So simply copy the address of the wallet you want to stock up with bytes for transaction fees -- and the main payloads too, of course -- and in one transaction send as many as you need to. If you allow 1000 bytes for one transaction fee, then this might be 10 payments of 5000 bytes (plus the payloads) to cover a few small meet-ups; it might be 20 payments of 1 MB to fund a bot. It all depends on your needs. And all in one transaction!
Coin selection
From a tonych Slack post 2018-04-04 16:36:
tonych [5:36 PM]: regarding coin selection algorithm, it is currently designed to minimize the number of consumed outputs (to minimize merging for better privacy). It first tries to find an output that is larger than your target amount. If this fails, it then tries to compose this amount out of smaller outputs, starting from the largest one. If there are any unconfirmed funds, they are, of course, excluded from selection.
This was prompted by someone who had sent 20x 10,000 bytes to the same address to cover transaction fees. Later, he made a 95,000 byte payment and the wallet used 10 of those 10,000 byte payments to pay it.
So, in preparation for being able to make 20 rapid transactions, you might want to use 20 separate addresses in the same wallet and send (say) 10,000 bytes to each, rather than 20x 10,000 bytes to the same address.