Topic: Speed up confirmation time (Read 2826 times)

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

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?

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

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? :-))

Transactions are almost instantly transmitted to the entire network.

Confirmations average about 10 minutes.

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

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

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

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.

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

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.


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.

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.

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.

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.

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

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

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://bitcointalksearch.org/topic/instawallet-introduces-new-approach-to-instant-payment-green-address-technique-32818 that the concept was already discussed in 2011.

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

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.

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.