Topic: Something strange here.... (Read 1979 times)

ok thanks seems complex but if its all back end stuff guess its fine

Not correct.

The blockchain ONLY cares about inputs and outputs.  Each tx creates separate outputs and uses older unspent outputs (making them spent) as inputs.  So if one receives 1 BTC, 0.5 BTC and 0.2 BTC at address X.  The amounts are "seperate".  Nowhere at the protocol level is there "1.7 BTC at address x".  There are three distinct unspent outputs to address X in the amounts of 1.0, 0.5 & 0.2 BTC.  One can create a tx spending one or more of them if one has the private key for address X.


There is no such thing as "total value" at an address at the protocol level.  Now your client will scan the blockchain and give you the total but that is merely an abstraction.  When your wallet shows "balance: 1.000 BTC" what is really means is that "as of the current block I have scanned the entire blockchain and located in the blockchain unspent outputs for addresses that I have the corresponding private key and the sum of those unspent outputs is 1.000 BTC"

I don't think anyone addressed this bit. The answer is no, the amounts aren't kept separate. It's only when an address is an INPUT that its entire amount gets spent. You can have several transactions send to the same address, and the address only stores the total balance (though the blockchain keeps a record of each transaction, and so will your client if you can be arsed to look, which I usually can't).

Make the payment threshold from your pool the largest you are comfortable with.  Each tx is a separate unspent output.

You can send transactions to yourself.  If you just do sendtoaddress, you won't necessarily collect the small transactions that you are hoping to collect, unless you send your entire balance to yourself.  Which isn't necessarily a good idea, by the way.

Or, you can use the raw transaction API to collect the small transactions and send them to yourself, manually.  This is a hassle, but works well, particularly once you have it scripted.

its just im a small time miner so i have payments of .3-.5 btc and id liketo mitigate fees as much as possible as it increases

You don't have to merge them to spend. Your client will automatically combine multiple outputs to create a transaction. So in the previous example where you have outputs: 10 BTC, 30 BTC and 60 BTC; if you want to send 80 BTC, your client will take 60 BTC and 30 BTC outputs to create a 90 BTC transaction: 80 BTC will go to the address you want to send to, and 10 BTC will go back to your wallet to one of your change addresses. You don't really need to think about these things as it's handled automatically under the hood.

You don't.  You just spend them.

thanks for explaining that seems wierd but if it works, so if my pool payouts keep going to one address then its still keeping the amounts seperate?

so how would you merge small amounts back into a single input output thing for spending

No. The above is true only if you have 100 BTC as one unspent output. Output is, simplifying, what you received in a transaction. So if you have 100 BTC which you received as a single output of a a single transaction, then what you above wrote is true.

But if you first received 10 BTC, then 30 BTC and then 60 BTC in three separate transactions, then you have in total 100 BTC but in three separate outputs. When you send coins, entire outputs need to be spent (not entire wallets), so if you send 5 BTC, bitcoin client will send the entire 10 BTC output (and this will be an input of the new transaction): it will generate 5 BTC output to xxxyz and 5 BTC output to a change address that you own. You will now have previous unspent outputs of 30 BTC and 60 BTC and a new output of 5 BTC.

(that is, assuming for simplification, that bitcoin client chooses the 10 BTC output to use for this transaction; if it chosen 30 BTC, then it would send 5 BTC and 25 BTC change and after the transaction you'd have previous unspent outputs of 10 BTC and 60 BTC and a new output of 25 BTC in your wallet).

Edit: corrected inputs into outputs.

There is no system. Your client creates a transaction with a 100 BTC input and a pair of outputs 95 & 5 BTC.  The protocol doesn't know or care which is the change address.  It merely sees a valid tx with 100 BTC input and 100 BTC output(s).

so to simplify and clarify.

i have 100 btc in a wallet,
i choose to send 5btc to address xxxyz
bitcoin sends the entire 100btc to the system,
then directs 5 to xxxyz
and returns 95 to an address it makes from the keypool before hiding it

Perhaps, but they're the easiest way to reassure yourself things are really happening, which is comforting when you just clicked a button in a beta software and are wondering if it actually did what it said it would.

You can blame the blockexplorer sites for causing the confusion on users.
Bitcoin users shouldn't be using those sites before understanding how bitcoin works, unless they like to be "the ox looking at the palace"...

There are no perfect solutions to this problem, but a decent one might be:

Always show all addresses that have ever been used, as in received funds. So after change address has been used, it's starting to show in your addresses list. Additionally, at the first time when change address is used, the client would show a popup message to the user explaining in few simple words change addresses concept and telling that they will be shown in their address list as they're being used. That popup would have “Understand. Don't show me this in the future“ checkbox and the “OK” button. Show it every time a new change address is used and until the user checked the “Don't show me” option.

This would trade the current questions for different ones, but at the same time it should decrease number of these new questions by order of magnitude and help more users understand what's going on.

Oh, agreed, but I am not sure casual users care so much about privacy.  They are also unlikely to use coin control or something to be mindful of linkage, so they harm their own privacy anyway*.  If these assumptions are correct, it seems silly to use random change addresses when the user doesn't want them and is actually confused by them.  At least, it should be configurable.

* Although if multi-party transaction creation like this were to become common, linking your change addresses wouldn't necessarily disclose they were owned by the same person.

Using a single key means that every single transaction you ever do it absolutely linked.  With random change addresses, there is sometimes a little linkage, but it isn't as easy or as automatic to track you.

Agreed, or at least it would be difficult to show change addresses without confusion.  This is part of why I prefer to just get rid of change addresses.  Perhaps the simplest abstraction is having just one address, like how you only have one bank account number.  It's still a little weird to see your entire balance spent and then part sent back to you, but at least the questions go from "how'd this random address steal my money?!!" to "why does my entire balance get spent and then returned to me?"  It's just a trade of questions as you say, but maybe a step down in panic levels is worth it.

I'm thinking about writing a proposal for some kind of "user profile" selection wizard when you create a new wallet.  It asks questions about how advanced you are and what your use cases are in order to configure settings, like a new one to just use one address.  Has someone written this up already?  On the other hand, that effort might be better spent trying to make the current system more understandable.  (Or is that a lost cause, and new users who poke around on blockchain.info are just going to have to experience some confusion?)


What do you mean?

Unhiding change would not in any way reduce confusion.  It would just trade the current questions for new different ones.  Plus, it would make the default to spray information around the network.  Not a good trade.

That is a good point.  If the hidding of change addresses made sense at one point it certainly doesn't now.  It causes nothing but user confusion.  I have never encountered a user who said "thank goodness the wallet hides some addresses from me".

Now hiding unused keypool addresses "might" make sense but even that should be visible via an advanced menu option.

If you click NEW ADDRESS then a "hidden" keypool address becomes visible.
If you receive funds at an address from the keypool it become visibile.
If your wallet sends funds to a keypool address as a change operation is remains invisible.

Which one of these is different.

The wallet hiding addresses WHICH HAS VALUE (i.e. unspent outputs) is horrible design.  It can ONLY lead to loss of funds.  Showing change addresses (i.e. you create a tx and it uses address 123.... as change and now 123.... shows in list of addresses) might lead to some user confusion but it won't lead to losing funds.

Hopefully someday the authors revisit this.  Since sites like blockchain.info exist and are used (even by users who don't use blockchain.info wallet) to track the status of transactions hiding info in the wallet that is visible in third party sites is just poor design.  Honestly it only remains due to inertia.

Given the current system, we still have users, who know their way around blockchain.info or another block explorer but haven't learned the "change address" concept ("wannabe power users" as you would probably call them; I'm not that blunt), getting confused and, you guessed it, asking for support.

This may not be the place to delve into this, but to elaborate: If there were an internal implementation requirement that change addresses must be used, you are right that it should be abstracted from the user.  Unfortunately people have perfectly valid reasons to sidestep that abstraction by going to a third-party service that doesn't know what their change addresses are and therefore can't abstract it for them.  For this reason (and the fact that random change addresses are not a hard requirement; only semi privacy-enhancing), my argument was that we should consider abolishing change addresses by default and just send change back to one of the spending addresses.  This still has potential for confusion, but I think less than seeing a destination address that the client intentionally hides the very existence of.  At least the confusion will hopefully not be the panic of "some random address hijacked most of my coins when I sent a few!!  this address is not listed in my client anywhere, I have never seen it before, etc."

It is either a technical change like stopping use of random change addresses, or trying to teach people why it's good that their spent coins get shuffled into random addresses that they didn't create themselves and are currently discouraged from viewing.  Which is easier?  Does the average user even agree with the rationale of change addresses?

And it looks like I put this in the wrong section to begin with.  Sorry about that, wasn't sure if it belonged here or there.

Well, at least in the debug console I can see what addresses exist in my wallet with "listaddressgroupings".

+1, it should be an option in the advanced settings.

it was excluded because it breaks the absraction of a "wallet". users do not need to know what a change address is, nor do they need to know what inputs or outputs are. this is the same reason why paypal/ach/sepa transfers do not disclose their internal implementation details. having that feature in the client complicates application design, and adds the burden of wannabe power users asking for support.

Huh, "change addresses".  Guess I missed that when I read up on things.

There any way to turn that off?  I'd rather it just use the one address on this install for everything, change included.

At least now I've got my Blockchain wallet (which actually has nothing in it) showing the correct total which includes the watch addresses I've added, after adding this change address in to it.

Yep, they are hidden on purpose, probably in a (misguided?) attempt to not confuse the user.  Every time I read a thread like this, I become more convinced that change addresses should be disabled by default.  Users who want the pseudo-anonymity offered by random change addresses, and who understand it, can re-enable it.

That would make sense, if that address showed ANYWHERE in the bitcoin-qt install, but it doesn't.  That's why I'm confused.

The only way I could find the 1Dkd7... address to begin with was to go like I was going to sign a message or request a payment.  Seems odd the Address Book won't show your own address by default.

It is called "change" and the balance was sent to a "change address".
Bitcoin CAN ONLY spend entire outputs. 

You had an unspent output worth 0.20560192 BTC.  You wanted to spend 0.1 BTC

Your wallet created a tx spending 0.20560192 BTC.  0.1 BTC to the address you specified and 0.10560192 BTC back to another unused address in your wallet.

I'm trying to figure out what happened with this transaction:
https://blockchain.info/tx/45d3052208af765202197260a4e70986155d1480ab1f1a2cf38f4dbe7da35386

It was sent from Bitcoin-qt installed in a Fedora 18 virtual machine.  According to Bitcoin-qt, all it sent was the 0.1 BTC to the 1C9PZ... address.  I did not enter the 1PSv3... address or any amount to go to it.

What is really strange about this is the 0.20560192 BTC amount in the output was the amount I originally sent to the 1Dkd7... address after I got Bitcoin-qt set up on the machine (it was the address it created for the new wallet).  It would not have surprised me to see that amount, if the remainder after the 0.1 BTC to 1C9PZ... had been sent back to the 1Dkd7... address.

Any ideas how that 1PSv3... address got there?  I went ahead and password-protected the wallet using the in-program option for that.  Had to enter my password to send it to begin with.

Even weirder as I look at this some more.  The 1PSv3... address does not show up on any other transactions on Blockchain.

What the heck?