Topic: please restrict "changeback" amount - page 2. (Read 3679 times)

This is the problematic part:


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.

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.

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?

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.

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

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

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.

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).

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

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.

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).
 

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.

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)?

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.