Speed up confirmation time

[mtomcdev]

I believe that Mycelium (android) wallet has a feature which checks recieved payments for a) a fee and b) propagation across the bitcoin network. if both of these are detected, the payment is labelled as 99% safe, even with 0 confirmations.
[Note, I have never used Mycelium wallet so my description might be a bit off]

I understand checking the fee and propagation is sufficient to look up the transaction, but such check doesn't prevent double spending or does it? I could be wrong, but I think to prevent double spending would need more validation.

A well propagated transaction with a proper fee is very difficult to cancel.  It isn't impossible, but it is beyond the risk threshold of most businesses.

This is what most people forget when they claim "Bitcoins will never be trusted for quick, in-person transactions!"

Businesses already accept a certain amount of risk when dealing in conventional payments: cash could be counterfeit, credit cards could be stolen, customer could be pulling some other kind of elaborate scam. There is much less risk involved in accepting bitcoins before their first confirmation as long as certain simple precautions are taken (i.e. verifying the proper fee was included).

Could you help me understand how the checking of the transaction fee is an effective precaution? If I understood correctly how the whole thing works, if someone want to perform a double spending with 10 BTC then including 0.001 BTC transaction fee is very minor cost comparing to the possible gain from the malicious double spending, so I guess the double spender would be happy to include the small transaction fees in many transactions.

Anyway, you are absolutely right, Bitcoin is probably a lot safer than conventional payment methods.

[DannyHamilton]

Could you help me understand how the checking of the transaction fee is an effective precaution?

There are 2 common reasons that a transaction might not confirm, and a double spender will have an opportunity to replace the transaction with a different one that pays himself instead of the merchant.

1. If a transaction does not include a sufficient transaction fee, then miners will not have enough incentive to include it in the blocks they are working on.  After a few days, the network will forget about the transaction.  The attacker will then have an opportunity to broadcast a replacement transaction that pays himself instead of the merchant.

2. If a transaction is not well propagated, then many nodes and miners will not have seen the transaction yet.  This allows the attacker to immediately broadcast a replacement transaction to those nodes and miners and have a high probability that the replacement transaction will be confirmed instead of hte original one.  Since nodes will refuse to relay transactions with small outputs, unless they include a sufficient fee, the attacker can reduce propagation by reducing the fee.

If a miner includes a sufficient fee, then the transaction will be relayed by any node that sees the transaction, and there will be enough incentive to the miners for the transaction to become confirmed long before the network forgets about it.

A merchant can further reduce their risk by maintaining direct connections to the largest mining pools and any pools or miners known to accept low priority free transactions, and rebroadcasting every 2 or 3 days any transactions that they have received that haven't been confirmed yet.  This will refresh the transaction in the memory of the pools so they won't forget about the transaction, and will therefore prevent any replacement transaction from propagating to the pools and miners.

If I understood correctly how the whole thing works, if someone want to perform a double spending with 10 BTC then including 0.001 BTC transaction fee is very minor cost comparing to the possible gain from the malicious double spending, so I guess the double spender would be happy to include the small transaction fees in many transactions.

That fee is far larger than necessary in most cases.  The merchant would want to check the size of the transaction (in bytes, not in bitcoins), and then verify that a fee of at least 0.0001 BTC per kilobyte was paid.  Since most transactions are less than a kilobyte in size, this means that in most cases the fee would only need to be 0.0001 BTC.

[mtomcdev]

Could you help me understand how the checking of the transaction fee is an effective precaution?

There are 2 common reasons that a transaction might not confirm, and a double spender will have an opportunity to replace the transaction with a different one that pays himself instead of the merchant.

1. If a transaction does not include a sufficient transaction fee, then miners will not have enough incentive to include it in the blocks they are working on.  After a few days, the network will forget about the transaction.  The attacker will then have an opportunity to broadcast a replacement transaction that pays himself instead of the merchant.

2. If a transaction is not well propagated, then many nodes and miners will not have seen the transaction yet.  This allows the attacker to immediately broadcast a replacement transaction to those nodes and miners and have a high probability that the replacement transaction will be confirmed instead of hte original one.  Since nodes will refuse to relay transactions with small outputs, unless they include a sufficient fee, the attacker can reduce propagation by reducing the fee.

If a miner includes a sufficient fee, then the transaction will be relayed by any node that sees the transaction, and there will be enough incentive to the miners for the transaction to become confirmed long before the network forgets about it.

A merchant can further reduce their risk by maintaining direct connections to the largest mining pools and any pools or miners known to accept low priority free transactions, and rebroadcasting every 2 or 3 days any transactions that they have received that haven't been confirmed yet.  This will refresh the transaction in the memory of the pools so they won't forget about the transaction, and will therefore prevent any replacement transaction from propagating to the pools and miners.

If I understood correctly how the whole thing works, if someone want to perform a double spending with 10 BTC then including 0.001 BTC transaction fee is very minor cost comparing to the possible gain from the malicious double spending, so I guess the double spender would be happy to include the small transaction fees in many transactions.

That fee is far larger than necessary in most cases.  The merchant would want to check the size of the transaction (in bytes, not in bitcoins), and then verify that a fee of at least 0.0001 BTC per kilobyte was paid.  Since most transactions are less than a kilobyte in size, this means that in most cases the fee would only need to be 0.0001 BTC.

Thanks for explaining, it make sense and I start to understand why the transaction fee is important in the process.

[mtomcdev]

I have been trying to collect information and reading about the green addresses in the last few days. It seems to me that green addresses definitely could be a possible solution to speed up the transaction. I think one of the biggest problems with green addresses is that the user must have a deposit account and sufficient fund at the green address provider's system to move some money to the green address prior to the transaction and this money can be lost if there is a security breach like what happened at Mintpal not long time ago or something else goes terrible wrong and the green service provider is out of business.

[DeathAndTaxes]

I have been trying to collect information and reading about the green addresses in the last few days. It seems to me that green addresses definitely could be a possible solution to speed up the transaction. I think one of the biggest problems with green addresses is that the user must have a deposit account and sufficient fund at the green address provider's system to move some money to the green address prior to the transaction and this money can be lost if there is a security breach like what happened at Mintpal not long time ago or something else goes terrible wrong and the green service provider is out of business.

The green address concept can be done in a trustless fashion using nlocktime txns.

[BurtW]

I have been trying to collect information and reading about the green addresses in the last few days. It seems to me that green addresses definitely could be a possible solution to speed up the transaction. I think one of the biggest problems with green addresses is that the user must have a deposit account and sufficient fund at the green address provider's system to move some money to the green address prior to the transaction and this money can be lost if there is a security breach like what happened at Mintpal not long time ago or something else goes terrible wrong and the green service provider is out of business.

The green address concept can be done in a trustless fashion using nlocktime txns.

I would not trust anything this guy has to say until he gets to 16,000 posts

[Alchemix]

I dont think 10min transactions times are all that bad.
Thats like 2 red lights in L.A.

[BurtW]

I dont think 10min transactions times are all that bad.
Thats like 2 red lights in L.A.

Transactions are almost instantly transmitted to the entire network.

Confirmations average about 10 minutes.

[mtomcdev]

I have been trying to collect information and reading about the green addresses in the last few days. It seems to me that green addresses definitely could be a possible solution to speed up the transaction. I think one of the biggest problems with green addresses is that the user must have a deposit account and sufficient fund at the green address provider's system to move some money to the green address prior to the transaction and this money can be lost if there is a security breach like what happened at Mintpal not long time ago or something else goes terrible wrong and the green service provider is out of business.

The green address concept can be done in a trustless fashion using nlocktime txns.

Could you explain briefly how a trustless green address with nlocktime would work please? It would be great to understand how the pieces fit together. I am sure that is an option, but I have just checked the nlocktime, I could be wrong but it seems to me that using nlocktime would delay the transaction and therefore increase the transaction acceptance time. Is that correct or I just misunderstand the whole thing again? :-))

[tryexcept]

The nlocktime part is to prepare some transactions that can only be used in the future to unlock your funds from the green address provider.
This is so you don't have to fully trust the green address provider.

That's how greenaddress.com works.

You can find more information on it here http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf

[mtomcdev]

The nlocktime part is to prepare some transactions that can only be used in the future to unlock your funds from the green address provider.
This is so you don't have to fully trust the green address provider.

That's how greenaddress.com works.

You can find more information on it here http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf

Thanks, I appreciate the explanation, but I couldn't find any references to the nlocktime in this whitepaper and I am having problems with geting my head around this :-)) So does it mean, the green address provider perform the transaction, and then withdraw the fund from the transaction that was initiated with the nlocktime, and if the greeen address provider is out of business and the transaction was never performed then the nlocktime expires and the fund remains on the address?

[tryexcept]

Imagine you sending all your bitcoins to a multisig 2of2 where you hold one key and some third party holds the other.
This third party can now prevent you from doing double spends and if people trust this third party then they can accept bitcoin transactions with 0 confirmation, assuming the third party does reasonable checks on fees and the number of confirmations the bitcoin you are sending have already.

But What happens if the third party disappear?

To solve this problem the third party presigns its part of the 2of2 a transaction from the 2of2 back to you but adds a time lock such that even if you sign your side of the 2of2 you can't broadcast the transaction because it can't get included in the blockchain yet.

This means that for each transaction you receive or make if it has any change you'll be able to download or  receive an email with the transactions as per above which will allow you to get your funds back in case the service is gone.

The system can be trustless once external malleability is prevented but at this time this can't be completely trustless. In GreenAddress' case in case a transaction gets included in a malleated form then you will receive a new presigned transaction automatically.

Hope this explains it a bit, feel free to ask any question