Bitcoin Forum

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.

It is how Bitcoin works.  You have pointed out a very real shortcoming though.  I'm not sure how this could be fixed aside from allowing transactions to be created based on unconfirmed funds, which runs a risk of accidental double-spends.

Isn't there an option to allow unconfirmed transactions to be sent?

Couldn't a wallet that is designed to be used for payments like this just break up large unspent outputs in advance?

Or you could make those two payments in one transaction and problem solved...

Not as an input to another transaction.  I'm pretty sure even qt nodes would reject such transactions.

This works if you can pay them all at the same time.  But there are certainly instances where you might need to make multiple payments in quick succession without combining them.  Paying a bar tab and then a taxi is a good example.  Or even visiting a bunch of vendors at a street fair and buying things from each.

Well it solves it in that situation, but I can think of plenty more it won't.

The only real answer is unconfirmed transactions or a centralised solution.

Yes, it's a problem, but I don't see mobile payments being used that way, cash is still the most effective payment method for everyday small payments.


Well, off-chain transactions is an option...

Are you certain of this? I've always been under the impression they could. Now I'm not sure.

Unfortunately, not solved. The bar has a separate address for the bill and bartender tips, something I do not have control over.

Well, exactly.  That's why OP is saying Bitcoin is going to have trouble going mainstream - because "cash is still the most effective payment method for everyday small payments".  Bitcoin still has its internet niche, but unless payments can be made flawlessly in meatspace as well, I tend to see Bitcoin as staying a niche currency and not going truly mainstream.


I am not certain.  We should seek out the truth.

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.

I'm not convinced that you are both interpreting what is being said in the same way.

It is possible to use an output from an unconfirmed transaction as an input into another transaction.

However, it is a dangerous thing to do due to transaction malleability.

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.

This is what I was getting at, surely it would be a fairly simple option for a wallet to have?

That seems like a solution that could avoid most instances of the issue I posted. I'll pass it on to Hive in my support ticket to at least get their response as a wallet designer.

But will nodes relay a transaction with an outpuu from an unconfirmed transaction used as an input for another transaction?  I was always under the assumption such a transaction would not be relayed until the first transaction confirmed.

I'm not familiar with the dangers of transaction malleability and how it would apply here.  Can you elaborate?

It's not something the mainstream user should have to deal with though, not to mention that it could introduce additional fees to the user.  But yes, it seems like a decent option until something better comes along.

Yeah effectively this could have been done in a single transaction with one output being used to pay for the bill and one output being used to pay a tip. Also, it would require only a single transaction fee. But yeah, maybe something needs to change here, if it hasn't been tackled somehow, already...

Yes.  That is why transaction malleability is a problem.


Then you were under a mistaken assumption.


When spending an output, transactions use the hash of the transaction that created the output to identify the output being spent.  Unfortunately it is possible to modify a transaction in such way that it still leaves the modified transaction "valid".  This results in the transaction having a new hash value.

If:

• You try to spend the output before it is confirmed
• Someone else modifies your transaction so that a copy of it with a different hash gets relayed
• The modified copy gets confirmed instead of your original transaction

Then you're second transaction that attempted to spend the output of this transaction will no longer be valid since it will be trying to spend an output from a transaction hash that no longer exists.

If you wait until after the first transaction has confirmed before sending the second, then the malleability problem disappears, since your wallet can use the transaction hash from the blockchain with confidence that the hash won't change in the future.


While I agree that dealing with this will be a hassle for the average user if they don't use off-chain centralized solutions...

Because bitcoin spends outputs, and creates new outputs that must be referenced to be spent, I don't think this is going to change.

If the malleability issue was resolved, would spending unconfirmed outputs be then realistic or still too risky.

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

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.

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.

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.

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.

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.

Thanks for the explanation DannyHamilton!

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.

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.

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!

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.

use two wallets.

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.

[/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.

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

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

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.

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.

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.

Right. Since the transaction malleability attack, It's no longer safe to spend unconfirmed change. So a spend locks up some unspent funds until confirmation. A better fix for transaction malleability may remove this limitation.

The stock wallet already tries to put together spends efficiently, given the items you already have in your wallet. Sending the contents of your wallet to yourself to break up big items is possible, but probably shouldn't be automatic.

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.

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

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

They must all be accessible using one password/key

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.

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

I have. My fiat confirms immediately.

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.

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

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.

I am pretty sure coinbase and bitpay merchants accept smaller unconfirmed transactions so it seems , Coinbase/Bitpay  think the benefit outweighs the risk.

These coffee/beer/food 0-confirmed transactions have been happening for ages. Its just the large transactions people wait 10-30min if need be.

Unconfirmed transactions are not risky due to the malleability issue unless you are relying solely on the tx id. You can safely use unconfirmed transactions as long as you don't use only the tx id to track them pre-confirm.

Oh right, so they are safe. So if the various wallets allowed unconfirmed inputs to be sent without using tx ids, problem solved.

Now I'm confused.

You are confused because you are talking about two completely different things as if they are both the same thing.

Thing number 1: Accepting an unconfirmed transaction that is funded by confirmed outputs.

If someone sends you a transaction, and the transactions that the inputs come from are confirmed, then malleability doesn't affect you.  As long as the transaction is well propagated and includes an appropriate fee, it's a pretty small risk to accept it.  For small value payments, most merchants would consider this an acceptable risk (probably a lower merchant risk than shoplifting, chargebacks, and counterfeit bills).

Thing number 2: Spending the output from an unconfirmed transaction.

If you receive an unconfirmed transaction, and then try to spend those bitcoins that you just received before they have confirmed, you then have a problem with malleability.  The transaction ID of the unconfirmed transaction could change before it confirms, which would then make your transaction invalid.  While it is often reasonably safe to accept unconfirmed transactions, it is never very safe to spend those bitcoins until the transaction has confirmed.

Thank you for your response. I am talking about #2.

There is a nice detailed summary here if you want to read more:

https://bitcointalk.org/index.php?topic=460944.0

As Danny says, #1 and #2 are different beasts. Transaction malleability alone isn't an issue unless you are relying solely on the tx id.  And it only becomes an issue if you combine it with attempting to spend those before they are confirmed.

Your problem is easily avoided by using coin control. That way, you can choose which coins to spend, how to combine them, and you will not be caught by surprise that you can't spend the change, because you will know exactly how much change there will be in each transaction, and where will it go.

Coin control is a feature, which currently only the original Bitcoin Core wallet has (as far as I know).

Armoury has coin control feature.

This is not true. The malleability risk is on the sender, not the receiver, and this is only when the TX ID is solely used to determine if you have sent someone funds or not. If you instead rely on something like, say the sending, receiving addresses, the date, and the amount then the risk is not there. If you only send a small number of TXs per day then you could simply remember if you paid someone or not. 

blockchain.info too

Anyway OP can alwaways send 22$ for the bill and 6 for tip in one tx, so no need to wait...
OR just spend the uncofrimed change.

For me this is not an issue and can be fixed by the software wallet you are using.

Yes OP, that's how it works, but that's necessary for it to function.

The main problem is with your wallet.

It should warn you, but still let you, use an unconfirmed output as a new input, so that exactly your situation can be done with quickly.  I'm sure not you nor the place you were paying would care about the risk associated with unconfirmed payments for that amount.   Your wallet should also have let you pay multiple addresses in one tx, so that you could have just done it all at once.  And finally, the establishment should also give you the option of just paying everything to one address, and it keeps track of what's what, although it could still provide separate tipping addresses in addition.

I think they show the payment as being received on the customer's end however would likely not credit the merchants accounts until after "x" confirmations. Also if the TX ends up not confirming they would likely advise the merchant as such and tell them not to deliver the product.

If you have to buy a stored value card, Bitcoin just gets in the way.

This is a situation the bar created for themselves. When you pay them in cash do you make 2 different payments, like if your bill is 22 dollars and you want to tip them 5 dollars do you hand them the 22 dollars and wait for them to put that in the register then hand them the 5 dollars, NO most people do not, you hand them the 27 dollars and tell them to keep the change they usually put it in a jar which at the end of the night is split between the workers. They are making you do their job. If it were me, (but I am an asshole) I simply would tell them no i will not pay the tip separately, I can either include your tipin this transaction and you document it, or I can just not tip you at all. How much do you want to bet they will say just include the tip in that transaction sir?

I will also bet the two addresses went to the same wallet just farther showing you, they are making you do their job. Its easier to look at the address at the end of the night and see how many tips came into that address and then distribute them that way rather than look and compare each transaction to see what the tip was. there are a lot of ways the bar can make that happen without inconviencing them or the customer, they just choose not to do thier job. BOTTOM LINE.

It's possible they implemented that setup without realising it would cause problems.  While it's good that companies are rushing to adopt Bitcoin, it's not as great if they rush in so quickly that they set it up in such a way that makes it problematic for the customers to use.  If you end up going back there, just politely explain it to them that two transactions won't work in quick succession (unless the customer has two wallets handy, which many won't) and they'd be better off just having the one address for customers to use and they can divvy up the funds later.

Bitcoin = gold

Some alt coin = paper money 

This is my bet.  Fastcoin for eg 12 seconds lol.

Your words is full of sense. He should get closer to Bitcoin system to understand how it's exactly works

Why couldn't a mobile app be developed that allowed deposits to it that are confirmed and in the user control? He can send it to any address and it automatically is deducted from his balance and can not be spent again. Doesn't matter about the transaction lag time and confirms. The btc was in a secure wallet. It was confirmed on the deposit. Should be able to spend it instantly.

I am not a cryptocoder but this seems an easy thing to do to me.

This situation was not caused by the bar, it was caused by the wallet software the OP was using. It is very well possible for someone to spend an unconfirmed input, it was just the software that was preventing it - the network would/should have accepted a 2nd transaction to the tip address.