Quote from: weilu on August 29, 2014, 02:25:42 AM

It seems to me that 3 solutions are proposed so far: 1. instead of a single output, break up the change output into multiple outputs of small amounts 2. allow user to specify multiple destination addresses in a single transaction 3. allow using unconfirmed outputs

3. is unsafe, as discussed above

1. only solves the problem partially -- it is still a problem when one spends the first funding transaction followed by creating another transaction immediately. In addition, setting the small amount threshold is a guessing work -- if the threshold is too big as relative to what the user normally keeps & spends, the same problem still exists. If it is too small user will end up paying additional fees because of the transaction size. I thought of this solution before, but in the end I thought to myself this would be the classic case of "software trying to be smart but ends up screwing with you and makes you hate technology"

Solution 2. seems like the only sensible solution to me, but it sure has UX implications for Hive (advanced send?). It does address OP's particular use case if he knows in advance that he wants to send x amount to addr1 and y amount to addr2, and decides to do it in a single transaction. Also it doesn't really address the "send one transaction followed by another" problem.

Keep the ideas coming. If we end up coming up with a good solution, I'm happy to implement it

Good post, and also an interesting problem. I've talked about earlier a method where you give away the private key, then receive the change to your wallet. For instance, let's say you have a wallet with 1 BTC, then you break it up in 5 adresses, containing 0.2 each, which would already make the solution much similar to suggestion 1. above. However, if there's a QR-code generated for one of those adresses, the waiter could scan it immediately on his phone, and then send you the change, so let's say you wanted to tip him 10 dollars (0.02 BTC), you just show him the QR-code, and he scans it, then scan a QR-code of a receiving address of yours and immediately sends back the change to you. That would be a little bit like having big bills, paying with one, and getting the change back.

Of course there would always be the risk of a double spend, but I do think that risk is negligible in most cases, you could also have some low value addresses for exactly this purpose. The biggest advantage of this would be that the receiver could be pretty sure he'd actually receive the funds, as he could immediately send it to another address of his, all of which could be automated in the software.

So if implemented in wallet software, the wallet could have some methods for splitting up inputs. These could be changed in a settings menu, and there could be some default parameters where the wallet was split up in 25% amounts, which would allow for at least 4 quick consequtive purchases. In the event someone usually needs to do more quick consequtive purchases, it could be altered in the settings menu. Of course, it would take a while for the changes to come into effect, because the transactions need to get enough confirmations. But if the hive wallet implemented something like this, then it should be possible to pay for a meal, give a tip and then proceed to take a taxi without problems.

The give a private key, and then get the change I think would work great for medium value stuff like purchasing a laptop at a physical store for instance.

An advanced wallet could implement several methods of payment as well, and as long as they also made the POS sw or coordinated with somebody that did, it should all be rather smooth for the parties involved.