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

[scribbles]

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]

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]

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

[Scott J]

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

[pedrog]

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

[SgtSpike]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[DannyHamilton]

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]

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

[pening]

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