please restrict "changeback" amount

[2weiX]

look at this transaction:
http://blockchain.info/de/tx/ee79c0ddc67ac3caeda766cdb1fd1114c87fb4d05a1b50d0a8f523f371c9a694

50BTC in address, I want to send 0.7x BTC to a friend.
Right AFTER that, I need to send 25BTC to somewhere else.... Pustekuchen!

My coins are stuck until the transaction is confirmed.
This REALLY grinds my gears.


Solution: Please restrict the changeback amount to 5% of the wallet balance.

[CIYAM]

If a lower UTXO does not exist there is no choice but to use the one it chose so is the problem that there was a lower UTXO that could have been chosen for this tx (sorry your "changeback" terminology is a little confusing)?

[2weiX]

If a lower UTXO does not exist there is no choice but to use the one it chose so is the problem that there was a lower UTXO that could have been chosen for this tx (sorry your "changeback" terminology is a little confusing)?

herpderp, I dunno. I'm not technically advanced enough to understand, it seems.
bang rock make fire?

maybe there's another way (a function "auto-spread balance across all addresses in wallet") to circumvent this problem.

[CIYAM]

The problem is fundamental to the way Bitcoin tx's work - it needs to use UTXOs (unspent transaction outputs - which are Bitcoin tx's that were sent to you) in order for you to send funds to someone else.

Typically the client will make random choices of UTXOs you have to build up enough (or often *more than enough*) BTC for the tx you are sending and will then send the *change* back to yourself.

From an anonymity point of view it is probably best that it actually chooses the UTXOs randomly (although an *exact* match might be a better selection if one exists).

In short though there isn't much you can do about this as fundamentally this is how Bitcoin works (you could of course send *yourself* smaller amounts if you want to create smaller UTXOs to be used in future txs although there is not likely to be any guarantee about which ones it will choose to use).
 

[Andreas Schildbach]

I'd like to add that Bitcoin Wallet does allow you to spend unconfirmed change.

However, the preceding transaction must have been validated at least by hearing it back from the network. You can tell that by watching the grey circle (initially a dot) grow. It can only grow if you're connected to the network after signing/sending the transaction.

[CIYAM]

Yes - assuming the minimal fee is paid then this is probably the only reasonable solution.

[2weiX]

I'd like to add that Bitcoin Wallet does allow you to spend unconfirmed change.

However, the preceding transaction must have been validated at least by hearing it back from the network. You can tell that by watching the grey circle (initially a dot) grow. It can only grow if you're connected to the network after signing/sending the transaction.

I know that, but people freak out when you tell them "sent" and they don't see the trx for another hour (especially in face2face transactions).

[Akka]

I know that, but people freak out when you tell them "sent" and they don't see the trx for another hour (especially in face2face transactions).

Problem is (like explained above) the way Bitcoin works.

In simpler terms, when you send BTC50 to an address (or your mobile Wallet) it is like you now have 1 BTC50 Bill.

Just like with an € bill you only can spend this entire Bill. If have want to buy something for 5 € you have to pay with you 50 € bill and get change back. You can't just rip out a pice of the Bill and pay with it.

With Bitcoin it's the same, you have to spend the entire BTC50 and get the change back.

(I know that this is oversimplified)

Simple Solution for your Problem. Instead of sending one BTC50 Transaction to your wallet, use more than one address and for example send a BTC50 Transaction with BTC10 to 5 Addresses in your mobile wallet, so now you carry 5 BTC10 "Bills" instead of 1 BTC50.

[2weiX]

I know that, but people freak out when you tell them "sent" and they don't see the trx for another hour (especially in face2face transactions).

Problem is (like explained above) the way Bitcoin works.

In simpler terms, when you send BTC50 to an address (or your mobile Wallet) it is like you now have 1 BTC50 Bill.

Just like with an € bill you only can spend this entire Bill. If have want to buy something for 5 € you have to pay with you 50 € bill and get change back. You can't just rip out a pice of the Bill and pay with it.

With Bitcoin it's the same, you have to spend the entire BTC50 and get the change back.

(I know that this is oversimplified)

Simple Solution for your Problem. Instead of sending one BTC50 Transaction to your wallet, use more than one address and for example send a BTC50 Transaction with BTC10 to 5 Addresses in your mobile wallet, so now you carry 5 BTC10 "Bills" instead of 1 BTC50.

Thing is, I cannot control how others send to me.
I'd really like to control this on MY END.

[CIYAM]

Thing is, I cannot control how others send to me.
I'd really like to control this on MY END.

You can't other than make sure that you provide a new address for every incoming tx.

[2weiX]

Thing is, I cannot control how others send to me.
I'd really like to control this on MY END.

You can't other than make sure that you provide a new address for every incoming tx.

That's what I can do NOW. And as I pointed out, I can't really control what others send to me.
Why I created the thread is so I can do something different (and more convenient) THEN.

[Mike Hearn]

Wait, everyone calm down for a second.

Ignore the solutions 2weiX is proposing for his problem. Focus on the fact that he/she has a problem in the first place! As Andreas says, it's allowed to send money as many times in a row as you want without waiting for a confirmation. Those transactions will get broadcast as soon as you have a network connection.

So, the real question we need to answer is - why do people not see 2weiX's transactions for "one or two hours"? That's way too long. The recipient should see the transaction immediately, within a few seconds. If the tx doesn't go out for multiple hours, that suggests a bug or failure somewhere.

2weiX - how are you sending these coins? When you press "send" on the screen, you should see the little grey dot grow. Do/did you see that happen?

[2weiX]

Wait, everyone calm down for a second.

Ignore the solutions 2weiX is proposing for his problem. Focus on the fact that he/she has a problem in the first place! As Andreas says, it's allowed to send money as many times in a row as you want without waiting for a confirmation. Those transactions will get broadcast as soon as you have a network connection.

So, the real question we need to answer is - why do people not see 2weiX's transactions for "one or two hours"? That's way too long. The recipient should see the transaction immediately, within a few seconds. If the tx doesn't go out for multiple hours, that suggests a bug or failure somewhere.

2weiX - how are you sending these coins? When you press "send" on the screen, you should see the little grey dot grow. Do/did you see that happen?

The scenario was (in two cases this hasd happened as of yet) the following:

I get sent a number of BTC, say 100.
I send away a part of those (be it paying for a drink, selling 10 BTC).
So let's say 10 BTC are sent to another person, 90 BTC are "changeback".
I can now send another 10 BTC to yet another person, the remaining 80 BTC being the "changeback".

I have now built a dependency cascade of a number of transactions which all depend on the first one "going through".
In my experience, those do not show immediately on the chain (the app's status shows "this transaction has not been sent yet").

Let's assume that for whatever reason, the next block takes 1h to find (or the app simply doesn't "see" the block).
Andreas was witness to one instance of this scenario (at the first BXB if you remember).

I had received 60 BTC
Paid my drink (0.01987something)
sold 10BTC
sold 10BTC
sold 20BTC
sold 10BTC
and was unable to spend the remaining BTC because the first transaction was still unconfirmed (in this instance, the app had not seen the next block, but there have also been times when a block took 30 minutes).

so I stood there in the rain, having a heap of unconfirmed sales and as number of unspendable BTC (maybe that depends on which version of the app I was using).

I wish there was an "easy" way for any user to circumvent such situations by eg. selecting "spread", which automatically adds 10 keys, makes a backup and then spreads the coins evenly in one transaction.

[Mike Hearn]

This is the problematic part:

I have now built a dependency cascade of a number of transactions which all depend on the first one "going through".
In my experience, those do not show immediately on the chain (the app's status shows "this transaction has not been sent yet").

Building up chains of unconfirmed transactions is not in itself a problem (they can/should all confirm together).

However, if the app says "this transaction has not been sent yet" then this means one of four things:

1) Your internet connection wasn't working.
2) You have set a "trusted peer" (this confuses the ui a bit - known bug, issue in bitcoinj really).
3) There's an unknown bug that was causing the transaction to not be sent.
4) There's an unknown bug that causes the transactions to be sent, but the app doesn't recognise it.

I have a vague feeling I might know what (3) or (4) could be. If you send a transaction and you don't have internet access at the time (or it's flaky etc) then the transaction won't be broadcast. You won't be allowed to extend an unbroadcast transaction chain (you won't be allowed to spend the change). However if you then regain internet access, bitcoinj will announce the transactions to all newly connected peers at once and thus won't get a chance to see them propagate.

Andreas, does that sound about right? If so, it should not be hard to reproduce this and verify the hypothesis. If correct then it should be an easy fix. It means changing how pending transactions are announced to new peers such that rather than announcing them as soon as a peer is connected, all pending transactions in the wallet are broadcast along the standard codepath (using PeerGroup.broadcastTransaction), to allow observation of the propagation.

It'd be even better of course if the P2P protocol informed you if a tx was rejected. Then we could simply this "seen by X peers" tracking code significantly. I might submit a pullreq to do that at some point.

[2weiX]

Okay you guys, please go about doing technical things to fix this, I'm more of a "user" type.

[Andreas Schildbach]

If you send a transaction and you don't have internet access at the time (or it's flaky etc) then the transaction won't be broadcast. You won't be allowed to extend an unbroadcast transaction chain (you won't be allowed to spend the change). However if you then regain internet access, bitcoinj will announce the transactions to all newly connected peers at once and thus won't get a chance to see them propagate.

Andreas, does that sound about right?

Although I only saw the result and not his actions, that sounds right. At least I had that happening to my wallet as well. It was never much of a problem, because my wallet is always fragmented enough so I can easily find another output to spend for my beer. But I agree it can be a problem for big transactions.

If correct then it should be an easy fix. It means changing how pending transactions are announced to new peers such that rather than announcing them as soon as a peer is connected, all pending transactions in the wallet are broadcast along the standard codepath (using PeerGroup.broadcastTransaction), to allow observation of the propagation.

Bitcoinj would trigger this internally, right?

It'd be even better of course if the P2P protocol informed you if a tx was rejected. Then we could simply this "seen by X peers" tracking code significantly. I might submit a pullreq to do that at some point.

Please do. The sooner we have this the better. We realized already a year ago how much this would simplify the interaction. An ack message would also be useful, by the way.

[Andreas Schildbach]

One more thought: The new offline transaction feature would have helped in this case - right? The only caveat is that currently, the feature does not transmit chains of transactions - only the transaction itself.

[Mike Hearn]

Yes, it needs to send a tx and all its unconfirmed dependencies actually. The wallet can have a method to provide such a collection.

I filed issues against bitcoinj for these two things.

[Peter Todd]

Yes, it needs to send a tx and all its unconfirmed dependencies actually. The wallet can have a method to provide such a collection.

I filed issues against bitcoinj for these two things.

P2P protocol changes to send multiple tx's in one packet are needed for child-pays-for-parent as well as replace-by-fee secured zero-conf transactions, so it'd be functionality that will get used by a lot of things.

[DeathAndTaxes]

Yes, it needs to send a tx and all its unconfirmed dependencies actually. The wallet can have a method to provide such a collection.

I filed issues against bitcoinj for these two things.

P2P protocol changes to send multiple tx's in one packet are needed for child-pays-for-parent as well as replace-by-fee secured zero-conf transactions, so it'd be functionality that will get used by a lot of things.

They don't need to be in one "packet".  As long as a node can validate the tx and any unconfirmed parents they will be relayed.  Technically it is likely the peer already knows about the unconfirmed parent but sending both just avoids the tx being dropped.

So for unconfirmed tx there is no issue (at the protocol level but based on OP report if accurate there is some issue with the client) in unconfirmed chains.   The main unresolved problem is that the algorithm in bitcoind used by miners to select tx for a block ignores child-pays-parent.

This means usually a tx with a high fee which has a unconfirmed parent w/ low/no fee ends up being delays.   It may take a considerable amount of time before a miner includes the low priority parent into a block and until they do so the high fee child is ignored.

Still all that has to do with first confirmation time.  The issue described by the OP is that down chain tx are "not seen" (meaning not even unconfirmed) by the receiver and reported by the client as unsent.  Unless the OP is mistake or my reading is incorrect that is a client side bug and not a restriction of the protocol.

I had received 60 BTC
Paid my drink (0.01987something)
sold 10BTC
sold 10BTC
sold 20BTC
sold 10BTC
and was unable to spend the remaining BTC because the first transaction was still unconfirmed (in this instance, the app had not seen the next block, but there have also been times when a block took 30 minutes).

What should have happened (even assumming empty wallet no other UXTO)

I had received 60 BTC
Paid my drink (0.01987something) - instantly sent - unconfirmed
sold 10BTC - instantly sent - unconfirmed
sold 10BTC - instantly sent - unconfirmed
sold 20BTC - instantly sent - unconfirmed
sold 10BTC - instantly sent - unconfirmed
I could send the rest without issue or delay

None of the tx would be included in a block until the first one was and since child pays parent is ignored by miners it may be a while but as far as unconfirmed tx there should be no issue.