please restrict "changeback" amount

[DeathAndTaxes]

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.

Your coins should never be "stuck".  The protocol doesn't require that.  This is a bug in the client.  Exactly how/why it believed you had no UXTO to spend I don't know but you should have been able to spend every single coin down to the last satoshi.

Important:  the subsequent tx won't CONFIRM until the first tx (drink) is CONFIRMED.  So since the first tx is small if you didn't include a fee it may be a while and even if you included a fee in subsequent tx they can't be confirmed until the first one is.  So if your buyers complained.  Dude these coins you sent me have been unconfirmed for two hours that would be a different issue however any bitcoin tx (unless it breaks min mandatory fee rules) should be sent immediately and be seen (unconfirmed) by the recipient within seconds at most.  This applies to any client on any OS anywhere in the world.   

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

This is impossible however it isn't necessary for the real solution.  You simply want to be able to spend all yours coins whenever you want.  That is possible however change is ALWAYS the amount of the input minus the output.

As someone indicated up thread in the real world you open your wallet and inside is a single $50 bill.  You want to buy a beer for $5.  You can't tear off a corner of the bill to pay.  Well you could but the bartender might decide you had one too many.  The only possible way to pay for the beer is to pay $50, the bartender will put $5 in the till and return $45 to you.

Bitcoin works the same way.  If you receive 60 BTC as single tx you have a 60 BTC "bill" you can't tear off a corner of it.  It doesn't matter if you intend to spend 1 satoshi or 20 BTC or 60 BTC the only possible way to "spend" it is in a 60 BTC transaction.

So change will always be the difference.  However this is an xy problem. http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

You don't really want to have the change smaller you just want to be able to spend all your coins when and how you want.  Luckily that problem can be solved and would appear (based on your description and assuming you didn't have one too many) to be a client side bug.

[Peter Todd]

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.

Transactions that don't pay fees, or only pay small fees, are ratelimited so you can't just assume they will be relayed.

Also you have to understand the fine details of how the network protocol works: everything a node knows about is part of its "inventory", and (almost) every time we get a new inventory item we advertise it to our peers by sending them an "inv" message containing the inventory type (block, filtered block or transaction currently) and inventory hash. Our peers then request inventory they don't know about with "getdata" messages; they do this pretty much as fast as they learn about previously unknown inventory items.

Now if your node gets a transaction that either doesn't pay any fee, or pays a very small one, storing it in memory could constitute a DoS attack by filling up your memory, so beyond a certain rate limit free transactions are simply dropped and won't get requested again. On the other hand when the child transaction comes in that does pay the fee arrives we won't even know it paid the fee because we don't have the parent, so it just gets dumped into the orphan tx holding area and aren't relayed to our peers.

In short child-pays-for-parent isn't reliable because you have no guarantee the parent will ever propagate, and thus no guarantee the child will either.

On the other hand if you can tell a peer "If you get transactions a,b and c you'll get xBTC worth of fees for yBytes of space" the child can propagate because peers know it's worth their while to get the parents txs. On the other hand implementing all that is tricky - you want to think about DoS attacks, not to mention the state required.

[Roy Badami]

4) There's an unknown bug that causes the transactions to be sent, but the app doesn't recognise it.

Just to say - I had this happen to me on 10 August (can't guarantee the wallet app was bang up to date).  The client got stuck on "this transaction has not been sent yet" even though the recipient had seen the transaction.  AFAICT the client continued to show "this transaction has not been sent yet" until the transaction confirmed.

I think I might indeed have had a slightly flaky Internet connection at the time.

roy

[Mike Hearn]

Were you using the trusted peer feature?

[Roy Badami]

Were you using the trusted peer feature?

No, I've never used it.

[Roy Badami]

I don't really understand the P2P protocol - how does the sender of a tx message know whether it was successfully received?   Does the receiver readvertise the transaction to the original sender in an inv message?

[Mike Hearn]

No. You have to connect to multiple peers and watch it appear at each of them (which is what the app does). Really the protocol should be way more explicit, but Satoshi didn't make it that way and we never upgraded it to be so.

August 10th is a long time ago now, the logs will be long since disappeared.

[Roy Badami]

No. You have to connect to multiple peers and watch it appear at each of them (which is what the app does). Really the protocol should be way more explicit, but Satoshi didn't make it that way and we never upgraded it to be so.

So if the network suffers an outage immediately after sending the tx message, you may miss seeing the transaction advertised by the other peers.  At this point you can try resending the inv and/or tx messages all you like but presumably you'll not get anything more back, right?

roy

EDIT: Oh, I guess you could poll peers with getdata to see if they have recieved the transaction.  That wouldn't even require multiple peers, would it?

[Roy Badami]

August 10th is a long time ago now, the logs will be long since disappeared.

It's only happened to me once, and I didn't even know that the client logged by default.  I only mentioned the date to give you an idea of what app version I would have been running.  But if it happens again I'll be sure to grab the logs.

[Mike Hearn]

If there's a network outage then it won't know the broadcast happened successfully, but when you reconnect it'll do a Bloom filtered mempool query and find the transactions at that point, so it's not a big deal. You can just press "back" and it'll figure things out eventually.

[Roy Badami]

If there's a network outage then it won't know the broadcast happened successfully, but when you reconnect it'll do a Bloom filtered mempool query and find the transactions at that point, so it's not a big deal. You can just press "back" and it'll figure things out eventually.

When you say 'reconnect' does this involve the client actually knowing that the network dropped first?  So if the inv packets from peers were simply dropped by the network, would you not just sit in the 'waiting for transaction to be sent' state?

[Roy Badami]

You can just press "back" and it'll figure things out eventually.

Thinking back, that's what I did, eventually, once I realised the transaction had in reality been sent.  And yes... it did figure it out eventually (i.e. when the tx was confirmed).

The problem is that this wa in a point of sale transaction at a pub, and I was standing there waiting while my phone said 'transaction not sent yet'.  Unfortunately, the design of the point of sale system is such that the bar staff have to press a key after I send the transaction - the terminal doesn't get notified asynchrounously.  So, unaware of this protocol failure mode, I just believed what the wallet was telling me.  I now know that what I should have done is ignored what the client was telling me and simply asked the bar staff to check if the payment had arrived.

But I shouldn't have to understand P2P protocol failure modes in order to use the app :-)

EDIT: Oh, it's TCP, so that shouldn't really happen.  Hmm...  (Somehow I was assuming the P2P protocol was UDP - dunno why.)

[DeathAndTaxes]

If there's a network outage then it won't know the broadcast happened successfully, but when you reconnect it'll do a Bloom filtered mempool query and find the transactions at that point, so it's not a big deal. You can just press "back" and it'll figure things out eventually.

When you say 'reconnect' does this involve the client actually knowing that the network dropped first?  So if the inv packets from peers were simply dropped by the network, would you not just sit in the 'waiting for transaction to be sent' state?

Your node (QT client) will periodically rebroadcast tx it has sent which remain unconfirmed.  It will continue to rebroadcast forever until either the unconfirmed tx is removed from the wallet (using a third party tool like pywallet) or it is eventually included in a block.

[Mike Hearn]

Right, I haven't seen the wallet fail to notice that it actually sent a transaction before but I can see how that might be annoying if it didn't work. If you see it happen again please send a report to Andreas using the settings screen.