Topic: Someone please tell me this isn't how transactions always work.... - page 3. (Read 4657 times)

There is also another issue here not been discussed yet. As we all know, keeping private keys on an online device is just not safe. I can't see that changing anytime soon.

Mobile device connected to internet with private keys? Just asking for trouble. Encrypting keys only has limited protection, as they need to be decrypted into memory before signing the transaction.

Sorry if I'm derailing thread a bit.

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.

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

He may have sent not $22 but $60, with $22 to the merchant and the rest as change back to himself. But that means there was no confirmed balance left to make another payment.

Can someone please explain to me what is happening here? He had $60, sent $22, why could he not send the $6?

If you already paid for the meal, why did you have to wait around for the tip to process?

[/quote]
To be fair, I think he was talking about multisend.  Unfortunately, I haven't yet seen a mobile wallet that has multisend capabilities.  It seems to be often overlooked.
[/quote]

Saw this, just this morning on reddit:

https://www.youtube.com/watch?v=T-CX-S8fq5A

From the video, it seems it has multisend capabilities.

It is indeed a Hive Wallet issue. The bitcoin network handles transactions with uncomfirmed outputs as inputs just as fine as it handle all the other Txs. Maybe you should switch to a wallet that does not limit you in your transactions and instead offers the featured the bitcoin network offers.

That said, you could have left and sent the tip later. It's not like you have to be right there in order to send BTC to their address.

use two wallets.

Problems like this will be worked out over time, I'm sure.

In the meantime, make sure you have more than one wallet installed on your mobile in case situation like that happens. There should be a backup plan to impress your friends : )

Also, if you use blockchain.info wallet or similar wallet with central server behind... the hardware on their side may be down, so it's cool to have another standalone wallet that connects directly to bitcoin network - just in case.

Remember: it's still early. As much as I'd like bitcoin to go mainstream, i personally think it's not ready yet.

this was because the whole balance was consumed in the payment and change address.  why couldnt Hive just implement some form of denomination so that a reserve of size (x) was always spent last and available for something else.  or make sure there are multiple inputs for a given wallet. so when spent it doesnt use the whole balance at once.
-just rambling (i dont use hive so unclear if possible)

Edit* looks like diamondcardz thought of this first, silly me for skipping ahead!

As people already shown, the fault is more how the apps are designed than in the bitcoin protocol.

Nothing that can't be solved with some work.

Or have a wallet which takes inputs over a threshold amount, say $20, and creates a transaction which breaks it up into smaller inputs by sending it as outputs to various addresses inside of the person's wallet?

>> EDIT: DannyHamilton already said this pretty much, I skipped over that bit.

Thanks for the explanation DannyHamilton!

There are many wallet services that will allow unconfirmed transactions to be sent. There are many transactions that have an unconfirmed input that are accepted by the network. How do you think shared send words on blockchain.info? It works exactly this way.
In the OP's case it would solve his problem.

If more clients supported multiple wallets, rather than just multiple addresses, perhaps this wouldn't be as much of an issue.  If you have three wallets with some BTC in each, then you can make three payments in quick succession.  Obviously it's not an ideal solution to the issue, but I don't get why only some clients support this feature.

It will be very difficult to eliminate all possibilities of malleability 100%.  However, if it could be eliminated, it would make spending unconfirmed outputs significantly safer, and acceptable in many cases.


The unconfirmed transaction would need to be confirmed eventually to have certainty and remove necessary trust, but there are many circumstances (such as tipping) where spending unconfirmed transactions could be acceptable if malleability weren't a problem.

They won't confirm until the original transaction does but in my experience nodes will not reject them. I spent unconfirmed change from blockchain.info in order to get a free transaction confirmed more quickly using child-pays-for-parent.

Some wallets allows change to be spent, which IMHO is the ONLY reasonable way for a wallet to work. Blockchain allows it, and I think Bitcoin Wallet for Android does as well,  but I'm not certain.

Surely spending unconfirmed transaction breaks the whole purpose of Bitcoin, to remove trust by replacing it with absolute certain confirmation of the transaction.