scribbles (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:14:04 PM |
|
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.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:17:05 PM |
|
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.
|
|
|
|
Buffer Overflow
Legendary
Offline
Activity: 1652
Merit: 1016
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:20:30 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
|
|
|
|
Scott J
Legendary
Offline
Activity: 1792
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:24:21 PM |
|
Couldn't a wallet that is designed to be used for payments like this just break up large unspent outputs in advance?
|
|
|
|
pedrog
Legendary
Offline
Activity: 2786
Merit: 1031
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:28:52 PM |
|
Or you could make those two payments in one transaction and problem solved...
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:35:22 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Or you could make those two payments in one transaction and problem solved...
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.
|
|
|
|
Buffer Overflow
Legendary
Offline
Activity: 1652
Merit: 1016
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:36:53 PM |
|
Or you could make those two payments in one transaction and problem solved...
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.
|
|
|
|
pedrog
Legendary
Offline
Activity: 2786
Merit: 1031
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:39:05 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Or you could make those two payments in one transaction and problem solved...
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. 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. Or you could make those two payments in one transaction and problem solved...
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. Well, off-chain transactions is an option...
|
|
|
|
Buffer Overflow
Legendary
Offline
Activity: 1652
Merit: 1016
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:40:17 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Are you certain of this? I've always been under the impression they could. Now I'm not sure.
|
|
|
|
scribbles (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 05:59:45 PM |
|
Or you could make those two payments in one transaction and problem solved...
Unfortunately, not solved. The bar has a separate address for the bill and bartender tips, something I do not have control over.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 06:02:02 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Or you could make those two payments in one transaction and problem solved...
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. 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, 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. Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Are you certain of this? I've always been under the impression they could. Now I'm not sure. I am not certain. We should seek out the truth.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 06:02:41 PM |
|
Or you could make those two payments in one transaction and problem solved...
Unfortunately, not solved. The bar has a separate address for the bill and bartender tips, something I do not have control over. 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.
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4790
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 06:09:40 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Are you certain of this? I've always been under the impression they could. Now I'm not sure. I am not certain. We should seek out the truth. 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.
|
|
|
|
Scott J
Legendary
Offline
Activity: 1792
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 06:38:33 PM |
|
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?
|
|
|
|
scribbles (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 06:57:22 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Are you certain of this? I've always been under the impression they could. Now I'm not sure. I am not certain. We should seek out the truth. 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. 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.
|
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 06:59:05 PM |
|
Isn't there an option to allow unconfirmed transactions to be sent?
Not as an input to another transaction. I'm pretty sure even qt nodes would reject such transactions. Are you certain of this? I've always been under the impression they could. Now I'm not sure. I am not certain. We should seek out the truth. 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. 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? 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? 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.
|
|
|
|
minerpumpkin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 07:02:49 PM |
|
Couldn't a wallet that is designed to be used for payments like this just break up large unspent outputs in advance?
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...
|
I should have gotten into Bitcoin back in 1992...
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4790
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 07:21:19 PM |
|
But will nodes relay a transaction with an outpuu from an unconfirmed transaction used as an input for another transaction?
Yes. That is why transaction malleability is a problem. I was always under the assumption such a transaction would not be relayed until the first transaction confirmed.
Then you were under a mistaken assumption. I'm not familiar with the dangers of transaction malleability and how it would apply here. Can you elaborate?
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. 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? 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. 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.
|
|
|
|
Buffer Overflow
Legendary
Offline
Activity: 1652
Merit: 1016
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 07:27:04 PM |
|
If the malleability issue was resolved, would spending unconfirmed outputs be then realistic or still too risky.
|
|
|
|
pening
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 27, 2014, 10:26:42 PM |
|
Surely spending unconfirmed transaction breaks the whole purpose of Bitcoin, to remove trust by replacing it with absolute certain confirmation of the transaction.
|
|
|
|
|