Someone please tell me this isn't how transactions always work....

[Krona Rev]

In my opinion, it seems it would be better for the wallet to break up larger outputs into multiple smaller outputs so that less total value is locked up in an unconfirmed transaction.

I think this is the best solution. While it would be helpful if a wallet offered to do this, people can do it themselves now. If you have $60 worth of btc at an address in your wallet, then do this: Before going out just send a couple of $20 transactions to two new addresses (or even to the same address) in your wallet. After that you should have 3 unspent txouts worth about $20. Then there's no need to make change. It's not so different from making sure you don't leave the house with only a $100 bill in your wallet.

[Buffer Overflow]

In my opinion, it seems it would be better for the wallet to break up larger outputs into multiple smaller outputs so that less total value is locked up in an unconfirmed transaction.

I think this is the best solution. While it would be helpful if a wallet offered to do this, people can do it themselves now. If you have $60 worth of btc at an address in your wallet, then do this: Before going out just send a couple of $20 transactions to two new addresses (or even to the same address) in your wallet. After that you should have 3 unspent txouts worth about $20. Then there's no need to make change. It's not so different from making sure you don't leave the house with only a $100 bill in your wallet.

No. An address when spent must spend it's total value.

[dserrano5]

(or even to the same address)

No. An address when spent must spend it's total value.

No. An output when spent must spend its total value.

[cmacwiz]

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.

Multiple wallets would be cool for crypto-budgeting. Grocery wallet, bar wallet, gas wallet

They must all be accessible using one password/key

[Envrin]

As others have mentioned, it's a Hive problem.  There's no reason to not let you spend your change.  Hive wallet created the initial transaction, so it knows full well the change transaction is legitimate, hence shouldn't require confirmation before allowing you to spend it.  Then as stated above, mining of unconfirmed txs like this is no problem.  As long as that first transaction hits the mempool first, it should be fine.

However, this does get to be a problem when it comes to multisig, if you're waiting for additional signatures.  Then the change on the input has to be locked, until the initial transaction is fully signed and broadcast to the blockchain.  However, that's not the case in this scenario.

[Krona Rev]

(or even to the same address)

No. An address when spent must spend it's total value.

No. An output when spent must spend its total value.

Yes. It's transaction outputs that spend their total value, not addresses. For people who use Bitcoin-QT, do a little experiment building a transaction with "createrawtransaction" in the Help>Debug>Console. DIY is the best form of education.

[boraf]

Alright, if my recent experience at a bar paying with bitcoin is any indication of how bitcoin transactions work, then mass adoption is very unlikely. Someone please tell me if this is how transactions must work, or it's just a Hive wallet issue.

I was at a bar that accepts bitcoin and wanted to pay my bill with btc. My Hive wallet had about $60 USD worth of coin in it. My bill was $22. The bar has a receiving address for the bill and a separate address for tipping the bartenders. I sent my $22 worth of coin to the first address. Then I went to send a $6 tip to the bartender address and my wallet said that 'Some funds are unavailable. To send this transaction you'll need to wait for your pending transactions to be confirmed'. So I waited. And waited. It took 10 minutes of sitting there (with my friend wondering why in the hell I think paying with bitcoin is so great) before I could tip the bartender and leave.

I contacted Hive and they said it depends on unspent transaction outputs. So if I had an unspent output of $58, it used that to pay the bill and was waiting for the change to come back so there wasn't another available unspent output to pay a $6 tip.

If this is how bitcoin transactions have to work, then I completely overestimated the usability of bitcoin for everyday spending. If I can't pay a bill, then immediately pay a tip, then walk outside and pay a taxi driver because I'm not aware of the unspent output amounts in my wallet then I'll just go back to cash or card.

Someone tell me this isn't how it has to work.

Many people already mention bitcoin payment isn't mean to be for the retail type establishment.

It is mean to gear toward internet type purchase when buyer won't mind waiting for a few hours for the transaction to complete.

[DannyHamilton]

For people who use Bitcoin-QT, do a little experiment building a transaction with "createrawtransaction" in the Help>Debug>Console. DIY is the best form of education.

If you are going to actually try sending any raw transactions, learn how to switch your wallet to operate on testnet.

It is a VERY BAD idea to try to learn to use raw transactions on the bitcoin network.

[SgtSpike]

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

#2 doesn't work either.  You may need to pay two people in quick succession without being able to pay them both at the same time.

"Here, hold on while I go to the next vendor booth over and buy a widget from him so I can pay you both at the same time."  Or the bar tab + taxi situation brought up by OP.  Or even forgetting to add something to your basket at the store - now you have to wait 10 minutes before you can pay for that last item that you ran to grab after you already checked out.

[TheFootMan]

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.

Well, if you don't store a larger amount than you can afford to lose, you should be fine. For instance, I would not carry around a stack of cash larger than I could afford to lose.

[wasserman99]

In my opinion, it seems it would be better for the wallet to break up larger outputs into multiple smaller outputs so that less total value is locked up in an unconfirmed transaction.

I think this is the best solution. While it would be helpful if a wallet offered to do this, people can do it themselves now. If you have $60 worth of btc at an address in your wallet, then do this: Before going out just send a couple of $20 transactions to two new addresses (or even to the same address) in your wallet. After that you should have 3 unspent txouts worth about $20. Then there's no need to make change. It's not so different from making sure you don't leave the house with only a $100 bill in your wallet.

I think this solution would create a lot of blockchain spam. It would also not be free as you would likely either need to pay a TX fee each time you did this or potentially by in the same situation that the OP was in after he paid his bill (waiting for the breaking up of inputs to confirm with a 0 fee TX). 

[Nagle]

As others have mentioned, it's a Hive problem.  There's no reason to not let you spend your change.

No, it's not a Hive problem. The Hive wallet is doing it right, and the Bitcoin Core wallet can do it right but is configured by default does it wrong. When the fixes went in for the transaction malleability bug, the configuration parameter spendzeroconfchange was added. By default, it's set to 1, which is the old behavior. It should be set to 0, but that was considered too disruptive at the time.

[gtraah]

There MUST be a way for your wallet to detect the amount that your spending coin from, Example :

1. I send $15 From Wallet A_(3xBTC available)  > Wallet B
2. Directly after I decide to send $5 from Wallet A_(2.98xBTC)

If Wallet app detects you have more than $5+Tx Fee it will allow you to send another payment without payment 1 confirming. BUT if you do not have funds for the 2nd transaction then the App detects a double spend attempt and says OUT OF FUNDS.... Previous Payment waiting for confirmation.


This seems like simple feature someone can implement into a wallet and I am extremely surprised it isnt in the wallet software right now

EDIT: SEE MY BELOW MESSAGE I JUST REALIZED WHY OP HAD AN ISSUE AND WHY I DIDNT

[gtraah]

I THOUGHT SO!.


I specifically tried this from 1 wallet to another wallet, and not even 20 seconds after I sent the first transaction, I sent another transaction from the same wallet. And they both worked, they are now both waiting for confirmations .

I use Mycelium , THE BEST Android wallet in my opinion.


The problem is for people who use Change addresses. THere is litereally no point in using Change addresses when your out doing shopping at the markets.

Offcourse you have to wait if your using a change address, because your effectively sending all your bitcoin to another address meaning you DEFINITLEY have to wait for it to confirm.

HOW TO SOLVE??

USE - MYCELIUM when shopping, it does not use change address, you can literally send 20 transactions one after the after to 20 wallets.

Its not a BITCOIN problem its a change address feature that caused that issue

OR

There should be wallet options to remove change address feature.. As said above there is no need for any change addresses when your out shopping, this is used for security, and for people moving big amounts from wallet to wallet or cold storage to cold storage. Wallets should have some sort of functionality implemented in the wallet where you can opt out of change address option before sending

[Swordsoffreedom]

Alright, if my recent experience at a bar paying with bitcoin is any indication of how bitcoin transactions work, then mass adoption is very unlikely. Someone please tell me if this is how transactions must work, or it's just a Hive wallet issue.

I was at a bar that accepts bitcoin and wanted to pay my bill with btc. My Hive wallet had about $60 USD worth of coin in it. My bill was $22. The bar has a receiving address for the bill and a separate address for tipping the bartenders. I sent my $22 worth of coin to the first address. Then I went to send a $6 tip to the bartender address and my wallet said that 'Some funds are unavailable. To send this transaction you'll need to wait for your pending transactions to be confirmed'. So I waited. And waited. It took 10 minutes of sitting there (with my friend wondering why in the hell I think paying with bitcoin is so great) before I could tip the bartender and leave.

This is a difficult question, your right having a timing limitation does present a real world problem that I am not sure how would be solved, sending a tip paying for a bill and taking a taxi are real world applications that should be done smoothly.
If possible Hive should allow users to spend up to their max balance without needing to wait for confirmations.

Perhaps a setting to allow unconfirmed txts to be sent as a double spend once the output is released should be improbable if not difficult to execute.

But two payments in one transaction may work but it would require the ability to send more than one address per transaction.
A good puzzle and i'm surprised no one brought it up sooner.

Perhaps having two separate wallets on the same phone, or finding a way to keep different balances all in one overarching user account.
That way an unconfirmed balance can come from one bitcoin address and any change could be taken from another.

[gtraah]

Ok In literally 8 minutes Both Separate transactions that I sent from the same wallet were confirmed one confirmed a fraction quicker than the other because I sent it first and now I have sent them back to the wallet I sent them from and it confirmed in 6 minutes WTF, I have never seen anything so efficient.. I sent and confirmed 3 transactions in 14 minutes And I did not have to wait to send the first 2 transactions I sent them one after the other, I obviously had to wait for them to appear and confirm in the receiving wallet so I can send them back And for ppl wondering about the TX fee? I paid 5 cents per transaction. (PEANUTS)

So there you go >>> TO THE OP>.. USE MYCELIUM . DO NOT use change address functionality when your out brick and mortar shopping.

[Buffer Overflow]

I sent them from and it confirmed in 6 minutes WTF, I have never seen anything so efficient..

I have. My fiat confirms immediately.

[gtraah]

Yes thats why those pieces of paper are so great you dont need them to confirm. *burp*

Anyway you don't even need to wait for a confirm if your buying food or drinks or whatever under $500  if clerk confirmed miner fee paid and transaction appears on his side then it is most likely paid and your good to go. After 1398 transactions in less than 1 year and not a single hiccup or failure. I think that's pretty good dam good.

[Buffer Overflow]

Anyway you don't even need to wait for a confirm if your buying food or drinks or whatever under $500  if clerk confirmed miner fee paid and transaction appears on his side then it is most likely paid and your good to go.

As discussed earlier, until the malleability issue is resolved accepting unconfirmed transactions is too risky at present.

[Erdogan]

A possible third party service could be envisioned:

A card, bought on airports and shopping centers, which has a public bitcoin address and a magstripe or chip or whatever is needed for the shop.

The user fills the card with any amount with a regular transaction

The third party, having the secret code and therefore the bitcins, can safely promise to pay to shops using traditional point of sale terminals. Immediate satisfaction for shops.

Third party taking suitable fees for itself

When you leave the area where the card is relevant, you empty the card to your own bitcoin wallet using an agreed code sent to the third party.

System like these (really gift cards denominated in bitcoin) can be created locally, and cards can be anonymous. Simpler than normal gift cards.

Gyft has done it, but without the physical card part, nor with the bitcoin denomination of funds throughout.