Topic: Solve this riddle (Read 2000 times)

Unfortunately, in this case, it is meaningful, you don't drop all your TXINs into a hat, you actually keep them apart.

Suppose I have $1 USD in my checking account.

I transfer my $1 to Bill online, who has $50.

Next, Bill transfers Mary $5.

Where is my $1? Does Bill or Mary have it?

The question is meaningless with anything fungible. Ownership doesn't track through a fungible account.

Hopefully, yes, unless the user has specifically stated otherwise (Coin control). Reason is is that high priority coins are actually free, so, the best method would be (Assuming you didn't care about mixing addresses), if:-
1. You can get a free transaction, use the highest priority input, but, use some sort of weighting system to try and weight it towards using old enough inputs that are closer to the value you're spending (So you don't reset the change for nothing)
2. If there's no free transaction, use the lowest priority coins (That aren't unconfirmed/from a brand new block), as, if you keep using the highest priority coins, then, you'll never get to a state where there's free transactions.

But, if you're like me, you never allow the client to prechoose, and, manually do everything yourself, I wouldn't want my gambling winnings to pay a real-life friend, as, that looks like I'm an addict gambler, I'm much rather use some input I got from a sale where neither address is really 'know' (I.E. google address and you won't find "JustDice.com" or something). On top of that, I like binding transactions up, if I have five inputs from a singular service of 0.01 (0.05 total), and, I'm paying someone 0.03, I'd rather place all the TXINs at 0.05, rather than 0.03, and, change myself 0.02, so that I have a larger TXIN that matures faster (Depending on how mature the inputs are already, however, that may or may not be worth it). In some cases, this can also result in a free transaction (As TXIN priorities are added together).

The correct answer is "there is no such thing as a bitcoin, so the question is meaningless".

This is by design as it enables proper fungibility, which is maybe the most important property of a currency (as opposed to just an asset).

This is the whole reason CoinJoin, for example, makes any sense. Inputs 1,2,3 and outputs 4,5,6. You cannot deduce which input paid output 6, not because it is hidden, but because the question doesn't make any sense (well, technically there is SIGHASH_SINGLE, but let's ignore that).

I guess it would depend on the wallet you are using.  The protocol doesn't specify, and doesn't care.  That detail is left for each wallet creator to decide for themselves.  In my case, I frequently use coin-control, so I get to pick which output is spent and which isn't.

Why don't you go look in the source code and find out?

Edit: I don't mean to sound rude, I am trying to look at the source code myself now. Anybody know where this logic is held?

Is this true? Do older coins get used first prior to newly deposited ones?

Excellent analogy!

This is bitcoin, not bitledger. All unspent amounts are "coins", that is why there is the change address, because you have to make change from your large coin to pay an amount smaller than that coin.

wow really educational thread 

OK you have enough answers now tell us the correct one if you are not trying to troll !!!

Your 1btc comes back to your current 80 Activity point! Try withdrawing and sending again..

Yes, it's client dependent on what coins it chooses to spend. If you have a 50BTC input and a 1BTC input, then tried to spend 5BTC, you'd 100% spend the 50BTC input, as, 1BTC doesn't cover it, it'd then return 45BTc change, and, you'd have a 45BTC input and a 1BTC input, unless, specifically told otherwise, in which case it'd use both (50BTC input & 1BTC input), and, get change of 46BTC, as, a singular 46BTC input, although, no client would do this automatically as it'd reset the priority of the address, lose anonymity, and, be absolutely worthless.

As an analogy:

Think of each transaction that you receive as being a single "coin" that contains an equivalent amount of a precious metal (gold?).

So if you receive 0.05 BTC, in this analogy you receive a single coin that contains 0.05 BTC worth of that precious metal.

When creating a transaction, you melt together enough of these "coins" that you hold, and recast a new "coin" for the person you are paying that contains exactly the amount you intend to send.  Then you cast the remainder of the melted "coins" into a "coin" as "change" that you keep.

Now, imagine your wallet has a handful of these "coins" from previous transactions that you've received:

• 1 "coin" with 0.5 BTC of precious metal
• 1 "coin" with 0.6 BTC of precious metal
• 1 "coin" with 0.25 BTC of precious metal
• 1 "coin" with 0.8 BTC of precious metal

You need to send 1 BTC to a recipient.

Your wallet chooses some of these coins (let say the wallet you are using decides to choose the 0.8 BTC "coin" and the 0.5 BTC "coin"

The wallet melts them together and you now have 0.8 + 0.5 = 1.3 BTC of liquid metal.  The wallet pours off 1 BTC worth of the metal into a new 1 BTC "coin" which you send off to the person that you are paying.  Then it pours off the remaining 0.3 BTC of metal into a new "coin" that you keep in your wallet.

Your wallet now contains:

• 1 "coin" with 0.6 BTC of precious metal
• 1 "coin" with 0.25 BTC of precious metal
• 1 "coin" with 0.3 BTC of precious metal

If we assume that your recipient had previously created a brand new wallet and then received a single payment of 50 BTC from someone. Then he now has 2 "coins" in his wallet:

• 1 "coin" with 50 BTC of precious metal
• 1 "coin" with 1 BTC of precious metal

All of this melting and re-casting is permanently recorded in the blockchain.  So by looking at the blockchain, anyone can see that the 0.8 BTC and the 0.5 BTC transaction that were recevied at your address were melted, and that 2 new coins were cast (one sending 1 BTC to the recipent's address and one sending 0.3 BTC to an address that your wallet happens to control).

Now your recipent is going to send 5 BTC to someone.  There are two ways his wallet could choose to do it.  Which method is used depends on the coin selection logic used in the wallet that he is using.

He could just melt down the 50 BTC "coin" and cast it into 2 separate "coins" (a 5 BTC "coin" and a 45 BTC "coin") sending the 5 BTC "coin" to his recipient and the 45 BTC "coin" to an address that his wallet controls.  If his wallet does this, it will contain the following:

• 1 "coin" with 45 BTC of precious metal
• 1 "coin" with 1 BTC of precious metal (the coin that you sent him)

Alternatively, he could melt both the 50 BTC "coin" and the 1 BTC "coin" together and cast it into 2 separate "coins" (a 5 BTC "coin" and a 46 BTC "coin") sending the 5 BTC "coin" to his recipient and the 46 BTC "coin" to an address that his wallet controls.  If his wallet does this, it will contain the following:

• 1 "coin" with 46 BTC of precious metal

With the first example, it is clear that "your coin" is still in the wallet of person that you sent it to.

With the second example, it is not possible to say with certainty how many of "your coin's" molecules made it into each of the newly cast coins.  At best, we can assume that the liquid was evenly mixed before casting the new coins, meaning that 5 / 51 ~ 9.8% of your coin has been send to the second recipient, and 46 / 51 ~ 90.2% of your coin is still held by the person that you originally sent the 1 BTC to.

Now, stepping back from the analogy to real world...

Without the precious metal that needs to be melted, this is how bitcoin actually works.  There isn't an "account" with a "balance", and there are no distinct unique "coin files" that can be tracked. Your wallet keeps track of individual transaction outputs.  When you want to send bitcoins, your wallet combines one or more of those previously received outputs into a single transaction that blends together all the value.  Then it re-assigns portions of that value to each new transaction output (including an output to send the "change" back to an address that your wallet controls).

The answer actually depends on the choice of inputs for the transaction from XXX to YYY.  However lets assume that XXX's controller sweeps all inputs into a single TX because I think that's the gist of your question. 

XXX at first with 51 coins has 1 coin from you and 1/51 of it's balance is from your coin.

YYY then gets 5 BTC from XXX, thus 5/51 of your coin is there. 

XXX still has 46/51 of your coin. 

The 1 BTC was destroyed when you sent it to XXX.  For your purposes it's either in YYY or ZZZ, the change address.

You can find out by looking at the 5 BTC transaction, opening up transaction details, and determining what transaction outputs make up it.

So, this means it is client dependent?
I'm not convinced that this the proper way to trace "my coin"

I'm not trolling, just speaking in terms that most people on here use to simplify the situation.

It is (supposedly) most likely at XXX, since the client will use old coins/transactions when sending 5 BTC from XXX to YYY.

Not sure if trolling but maybe it is educative to the one or the other:

In Bitcoin you don't spend coins or "from addresses" but "from transactions" (and miners may also spend new coins into existence).

This said, if the 1Ƀ was accumulated over time and the 50Ƀ in XXX were accumulated over time, they are really many transactions and not one address that you could spend.
Assume that XXX got transaction X1, X2 and X3.
Now that you send 1Ƀ there you create just another X4 and X1 – X4 are now spendable if you have the private key to XXX.
To send 5Ƀ from XXX to YYY you could send a new transaction Z1 consisting of X1 or X2 and X4 and if none of your addresses contains exactly 5Ƀ + fee, you end up with some left over that you could either send to a new address of yours, or back to YYY.

So bitcoins are actually never in addresses but in transactions and the private key of the recipient of the transaction can create new such transactions.