Speed up confirmation time

[mtomcdev]

I read a few discussions in this forum when experienced devs and community members said that there are ways and even services built on the Bitcoin network to speed up the confirmation time. Someone said that even instant confirmation is possible using some kind of trusted node or some other mechanism. I read those comments but never came cross with the specifics, so I am not sure what are the options and methods to speed up the confirmation time (if any).
Would you let me know please how the Bitcoin confirmation time could be speed up (even with a third party service) and if that is possible at all?

[1714975175]

1714975175

[1714975175]

1714975175

[1714975175]

1714975175

[1714975175]

1714975175

[1714975175]

1714975175

[DannyHamilton]

You appear to have misunderstood something.

Confirmation time in bitcoin is random with an average of a bit less than 10 minutes.

By paying a transaction fee you can increase the probability that your transaction will be included in the next block, but there is nothing you can do to make that block show up any faster.

[BurtW]

What you may be talking about is the possibility of accepting transactions as "pretty much valid" before the first confirmation since as Danny said the confirmation time cannot be changed.  This is called accepting a transaction with zero confirmations.

There are ideas floating around for this.  One example is that a third party would insure the transaction after a small amount of time but before the first confirmation.  If the transaction turned out to be bad and you did not get your BTC then the third party insurance would pay you the BTC you lost due to the fact the transaction never confirmed.  There would be a fee for this insurance and the better insurance companies would have methods to reduce their claims by studying the transaction to make sure it has a very good chance of getting confirmed.

Is that along the lines of what you are talking about?

[Mitchell]

What you may be talking about is the possibility of accepting transactions as "pretty much valid" before the first confirmation since as Danny said the confirmation time cannot be changed.  This is called accepting a transaction with zero confirmations.

There are ideas floating around for this.  One example is that a third party would insure the transaction after a small amount of time but before the first confirmation.  If the transaction turned out to be bad and you did not get your BTC then the third party insurance would pay you the BTC you lost due to the fact the transaction never confirmed.  There would be a fee for this insurance and the better insurance companies would have methods to reduce their claims by studying the transaction to make sure it has a very good chance of getting confirmed.

Is that along the lines of what you are talking about?

That is pretty neat idea to be honest. Would love to see something like that being made and I would be very interested in their way of handling "bad" transactions.

[BurtW]

A bad transaction is a claim on the insurance.  Nothing they can do but to pay the claim, possibly learn from the experience, and move on.  There is nothing they can do if a transaction that they thought was good turned out to be bad - probably because it was a double spend.

[Mitchell]

A bad transaction is a claim on the insurance.  Nothing they can do but to pay the claim, possibly learn from the experience, and move on.  There is nothing they can do if a transaction that they thought was good turned out to be bad - probably because it was a double spend.

Hmhm, well it's a very interesting idea and I would love to see it happen. However you would need to trust that party to be fair and honest, which could be a problem.

[BurtW]

Point taken.

Another idea that has been talked about is that if your BTC are coming from a well known trusted source like Mt. Gox inputs.io well some sort of trusted large node then you are safe in accepting them with zero confirmation.  This hightly trusted source of BTC would publish the fact that BTC coming from a certain address or set of addresses will all be good so you can trust the transaction without waiting for a confirmation.  Perhaps they back their claims with some sort of insurance/guarantee.

[Mitchell]

Another idea that has been talked about is that if your BTC are coming from a well known trusted source like Mt. Gox inputs.io well some sort of trusted large node then you are safe in accepting them with zero confirmation.  This hightly trusted source of BTC would publish the fact that BTC coming from a certain address or set of addresses will all be good so you can trust the transaction without waiting for a confirmation.  Perhaps they back their claims with some sort of insurance/garantee.

Well, if people decided to trust that one node, wouldn't those people be vulnerable to shady practices by the node owner?

[BurtW]

True again.  So, best to wait for one or more confirmations unless you are willing to lose a certain amount of BTC to fraud.

This actually may make sense in for example a coffee shop scenario.  Most people would pay for their coffee and the transaction would eventually confirm.  If only a very small percentage of people rip you off then your losses may still be less than losses and fees on conventional credit cards - so still a win overall even accepting zero confirmation BTC transactions.

[Mitchell]

True again.  So, best to wait for one or more confirmations unless you are willing to lose a certain amount of BTC to fraud.

I bet that Satoshi broke his brain over this issue and I doubt that we can find a better (better being faster, safer and fair) solution any time soon.

This actually may make sense in for example a coffee shop scenario.  Most people would pay for their coffee and the transaction would eventually confirm.  If only a very small percentage of people rip you off then your losses may still be less than losses and fees on conventional credit cards - so still a win overall even accepting zero confirmation BTC transactions.

This is the main reason why I don't see a problem in doing small transactions with Bitcoin. Even though I don't get why one would use Bitcoin in such a fashion, but that is my personal opinion.

[e4xit]

If the funds are sent from multi-sig inputs, one of which is a third party, then you can be *reasonably* sure that the level of collusion required to try and doublespend would probably not be worth it for low value transactions.

For example, there is a wallet provider called Greenaddress.it who deal in multi-sig. When I send you a payment from my wallet there both they and I must sign the tx. If I can see that the payment has originated from a (or specifically a Greedaddress.it) multi-sig address (and has a fee attached) I can be very sure that the chance of doublespend is low, i.e. I can accept zero confirmation payments with more security, no confirmation time speedup required.

Of course this is a degree of centralisation, and the merchant still requires myself and Greenaddress not to collude against them, but it is risk reduction.

This can be done without multisig too, 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]

[mtomcdev]

What you may be talking about is the possibility of accepting transactions as "pretty much valid" before the first confirmation since as Danny said the confirmation time cannot be changed.  This is called accepting a transaction with zero confirmations.

There are ideas floating around for this.  One example is that a third party would insure the transaction after a small amount of time but before the first confirmation.  If the transaction turned out to be bad and you did not get your BTC then the third party insurance would pay you the BTC you lost due to the fact the transaction never confirmed.  There would be a fee for this insurance and the better insurance companies would have methods to reduce their claims by studying the transaction to make sure it has a very good chance of getting confirmed.

Is that along the lines of what you are talking about?

Yes, absolutely I was talking about that, and as Danny has pointed out I misunderstood what confirmation means in this context. More precisely, I understood that the confirmation is possible only in after 10 minutes as the transaction must be included in a new block, so I should talk about speeding up transaction acceptance instead of speeding up confirmation.

Thanks for the replies, all of you provided me with really useful info. Probably I should not make any comments when experienced hero members having brain storming about possible solutions, but I think both the insurance and centralized multi signature based solution could work. I think we all subscribed to the core concept of decentralization, but there are use cases when a centralized multi signature centralized wallet is perfectly acceptable. I think majority of bitcoin transactions aren't darknet related, most of the users wouldn't mind to compromise on decentralization and having a centralized multi signature wallet in order to be able perform quick transactions.

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

[DannyHamilton]

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.

[gmaxwell]

It's infrequent that engineering finds a strictly superior solution, — even Bitcoin itself sacrifices many things compared to centeralized payment systems. Usually engineering is about navigating the frontier of best possible tradeoffs.  Within the Bitcoin ecosystem we can hit multiple points on that surface, as the OP notes... but asking to explain them all here is a bit too much.

For a taste of whats possible,  look up micropayment channels,  also look up green address instant transaction confirmation, look up sidechains / two-way-peg (as a more far out and general tool)...  

[mtomcdev]

Great, thanks for both replies, they are really useful. I think having fast transaction processing is really crucial for Bitcoin to go mainstream and to be able to use Bitcoin on many more use cases (e.g. at a vending machine and no one wants to wait 10 minutes at a vending machine).

Is the green address concept supported by the bitcoin protocol? I am checking the source but unable to find any references of green address, on the other hand I can see at https://bitcointalk.org/index.php?topic=32818.0 that the concept was already discussed in 2011.

[DannyHamilton]

Great, thanks for both replies, they are really useful. I think having fast transaction processing is really crucial for Bitcoin to go mainstream and to be able to use Bitcoin on many more use cases (e.g. at a vending machine and no one wants to wait 10 minutes at a vending machine).

Is the green address concept supported by the bitcoin protocol? I am checking the source but unable to find any references of green address, on the other hand I can see at https://bitcointalk.org/index.php?topic=32818.0 that the concept was already discussed in 2011.

Green addresses are a layer on top of the bitcoin protocol, not an intrinsic part of the protocol itself.

[edd]

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

[gmaxwell]

Is the green address concept supported by the bitcoin protocol? I am checking the source but unable to find any references of green address, on the other hand I can see at https://bitcointalk.org/index.php?topic=32818.0 that the concept was already discussed in 2011.

Don't confuse the "green address" stuff discussed in 2011 with the green address instant confirmation (a feature of the green address multisig wallet service), they're different.

The original green address stuff discussed in 2011 is a horrible systemic risk that was generally rejected by the community— thank god, otherwise MTGOX's implosion this year would have resulted in tens of millions of dollars to businesses spread all around the ecosystem.

[mtomcdev]

Thanks for all inputs about the green address. I am trying to collect all information about it that's available on the net and understand how it works. It seems green addresses are definitely a possible solution to speed up transaction processing.

[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