Topic: How does Blockchain.info determine one address sending to another? (Read 1713 times)

Ok, I was looking at having a list of voter addresses that would then send to either address 1Yes1lksd8sdf986ad5ffasd57a9 or 1No1dfs6as5f4asd3a4h587dfa. Before the vote, everyone would know how many voters there are, a list of all of the addresses, and you could verify that your address is on the list.

Then when it is time to vote you combine your wallet into a single address and send a mBTC or whichever to the address you support.

At that point, everyone can watch the tally as it comes through, they can verify that the right addresses are sending to the final addresses. Any address not in the list would be refunded. And any amount above the agreed upon vote amount would be refunded. The address with the most BTC wins.

I was trying to avoid the use of individual addresses because I did not want the man in the middle being able to play any role once the stage has been set for voting. I can see how pre-publishing a hash of the list could work, while also having the added benefit of not having a final result until after the vote is over as to not influence those who have not yet voted.

For the voting problem:

It would probably be best to give each voter a "yes" and "no" address that they are expected not to share with anybody else. They can then vote by sending the right number of bitcoins to one of those addresses.

You can decide what happens if they send to both addresses.

If you want the vote results to be public, then you can pre-publish before the vote a hash of the list of all addresses and voters. Then after the vote publish the list; everybody can make sure it hashes to the correct value, that it has the right list of voters, that it has twice as many addresses as voters, and each voter can check to make sure the addresses assigned to them are on the list.

And the voters could then look at the transactions in the blockchain during the voting period, to those addresses to audit the vote.

There's probably a complicated crypto protocol you could put on top to make the votes anonymous-but-verifiable, too -- so even the vote organizer doesn't know who voted for what.

I am.

No likely the wallet would use funds (if any) from other addresses to increase priority and reduce fees.

If you mean the user sends all of his funds to a single address in his wallet and then sends the funds to you well yes all the funds would be at a single address so that would be the source.  I would point out that would reduce the age of all the user's coins to zero and expose them to fees on all future tx until they "age" again.

This also won't work on shared wallets like instawallet or bitcoin exchanges where coins can be sent from any address regardless of what user does.

You seem to be trying to force a round peg into a square hole.

With a better understanding of this, I am wondering about this solution:


Before the Bitcoins are sent out, a Bitcoin user could send the amount (minus fee) in his wallet to the address he wants to use (within that wallet) to combine all of his BTC into one.

Then, if he sends from that wallet, it would come from that specific address.

Is this correct?

Ok, that clears it up quite well.

I suppose that I was able to see the exact transaction because I was using an address that I had not sent anything from before, and was the only address in use in my wallet (was using an Android Bitcoin Wallet app).

Bitcoin doesn't send amounts it allows you to "sign over" UNSPENT OUTPUTS. Address and wallet "balances" are merely an abstraction.  Behind the scenses bitcoin only works in unspent outputs.

If you have an unspent output of 20 BTC you must create a transaction of EXACTLY 20 BTC (including fees to miners).  Not 10 BTC, not 22 BTC.  Exactly 20 BTC.

So your wallet behind the scenes will send the amount you to the address you want and then calculate the "change" and send that to a new address in your wallet.

20 BTC unspent output = 10 BTC output (to destination) + 10 BTC output (back to an address you control)

The 20 BTC unspent output is now spent (worthless and can be pruned).  The two 10 BTC unspent outputs are now valid inputs for future transactions.

The difference if any (there is none in this example) is the fee to miners.    If you took a 20 BTC unspent output and sent only 10 BTC to your destination then you just gave miners a 10 BTC fee.

Ok, then it is the concept of "change" that I am not understanding.

If you have 20 BTC in address ABC123, why not just send 10 BTC to XYZ111? Instead of sending 20 and getting 10 back?

The current reference client doesn't support coin control (allowing the user to select the specific unspent output which will be used in the transaction).   This will be added as a command line feature in 0.7 but you shouldn't rely on it.   Users of other clients (to include ewallet and exchange accounts) won't have that ability.  Most users will be unwilling/unable to determine which unspent output was used prior to creating the transaction.

It depends on how the transactions that do the spending are constructed.

With the Satoshi client, your change is always send to a new address (for maximum privacy) so a typical transaction looks like:


Here XYZ111 is where you want to send your BTC to and JKL222 is your address for the change.


With transations like this you do not know (reliably) where your BTC are coming from. The next transaction will probably spend from JKL222 as ABC123 is all spent.

This in intentional in the Satoshi client so that it jumbles up the change and the sendee's addresses.

Different code bases do things different. For instance by default the bitcoinj code sends change to the first of your addresses used (I do not think there is a particularly deep rationale for this - it is simply the easiest to implement).

So for bitcoinj code a transaction looks like:


You could then reuse the change on BTC on ABC123

For blockchain.info I believe you can specify explicitly the change address to that you can pop your change back to wherever you like.


TL;DR
With the right transaction structure you can send from a predictable, repeatable address but you lose privacy doing this.

When you flip a coin, it either comes up heads or it comes up tails. So after a coin has been flipped, you can say which side landed. But a person who flips a coin generally can't choose in advance which way the coin will come up. So there's no conflict between "you can tell X after the fact" and "you can't choose X".

You can look at a Bitcoin transaction to tell where the coins came from. That doesn't mean those who form transactions necessarily have the ability to control where the coins come from.

I asked here earlier if a Bitcoin sender could tell a receiver what address that it will be coming from. I was told that the user would not know the address it was coming from. Thread: https://bitcointalksearch.org/topic/m.982559

But I ran a test transaction. I have address:
1KFxTa9tLiM9YayFkdtZ1QvoJs4f7aQhjT

and I sent to address:

1ELWAR1qFQbfmpMhcsTaBniFRLewrYqGo2

It shows up here as 1KFxTa9tLiM9YayFkdtZ1QvoJs4f7aQhjT to 1ELWAR1qFQbfmpMhcsTaBniFRLewrYqGo2

http://blockchain.info/address/1ELWAR1qFQbfmpMhcsTaBniFRLewrYqGo2

So, if I have the address 1KFxTa9tLiM9YayFkdtZ1QvoJs4f7aQhjT and I told the receiver to associate a transaction from that address with my information, would the receiver not be able to verify that any amount sent from that address is from that user?


I am thinking about this not only for merchant transactions but for a voting system I am developing where only people within a group can vote by sending BTC to a single address. The site would verify the source address as someone in that group and everyone would be able to view the vote counts via the blockchain to a "Yes" or "No" address. The reason you would want to know the source address is so that someone does not just pop up several addresses and send in false votes.

Any clarification would be helpful, I am digging deeper into the mechanisms of how things work and how to put it to use.



EDIT: Ok, I understand now. Clarification needed in my last post.