Impulse Review

impulse_review.md

(That's my attempt to understand what problem Impulse solves and how. I am not a designer/developer of this scheme.)

Problem

Regular Bitcoin transactions are not guaranteed until mined sufficiently deep in the blockchain. Unconfirmed transactions can be observed nearly instantly, but they cannot be trusted (could drop out because of insufficient fees, or double-spent).

Impulse Overview

Impulse Site, Specification

Impulse by Bitpay uses 3-party scheme with Payer, Operator and Recipient. Before making the payment (before Recipient is even known), Payer is locking certain amount of funds with Operator (in 2-of-2 multisig transaction, sufficiently mined). When Recipient requests a payment, the funds will be spent from that 2-of-2 multisig. Recipient can observe that one of the signers is Operator and therefore it can trust that this payment will not be double-spent. In essence, transaction is still unconfirmed, but now there is less risk of double-spending. Also, Operator may ensure necessary amount of mining fees.

There is also time-locked refund transaction to protect Payer from Operator. Operator guarantees to the Recipient that the refund is locked sufficiently far away in the future to have current payment confirmed.

Note that paychan (funds locked in Payer-Operator multisig) is compeletely consumed after making a payment. To enable next payment efficiently, Impulse allows for instant reopening of another paychan within the current payment transaction. To do that, the change is sent not to Payer's address, but to the same 2-of-2 multisig address with Payer and Operator. (With another refund transaction prepared for Payer's protection.) Once the first payment is confirmed, next payment can be performed with the same level of assurance. If the first payment is not yet confirmed, next Recipient could still have some level of trust since the first payment is authorized by Operator, and trusted not to be double-spent.

Impulse pros and cons

Pros:

• Impulse enables higher level of trust in unconfirmed transactions while having a very little risk caused by presence of Operator.
• Operator cannot steal or lose Payer's funds. Its only job is to ensure that unconfirmed payment is well-formed and reject attempts to double spend it.
• The scheme also allows to maintain a somewhat single payment channel while making transactions (paychan is relocated to a payment transaction). The minimal overhead is the initial transaction that opens payment channel.
• Each payment transaction could be time-locked itself (with shorter period than the refund locktime) to allow continuous payments to the same party (e.g. $0.1/minute for a video stream).
• Scheme allows combining several paychans in order to make a bigger aggregate payment or to "refill" the existing channel for future use.
• Scheme is compatible with Recipients who are not aware of the protocol. They will receive Bitcoin payment on their address and decide on their own whether to wait for confirmations. User's funds locked in a paychan can be spent anywhere.

Cons:

• Payment channels must be prepared up-front. If there is no enough payment channels to make a payment, user must wait till payment channel is prepared and funds are well-confirmed. That's a minor concern as user may have a enough of cash deposited to a payment channel like they have enough cash withdrawn from ATM for everyday payments.
• Impulse is still limited by the Bitcoin throughput. Making frequent and/or very small payments to random parties is not efficient.
• Impulse requires well-known trusted party or parties to ensure protection against double-spending and assure eventual confirmation. Wallets and apps supporting the protocol must be aware of a set of trusted parties that can assure these payments. This brings in all the difficulties of TLS certification and revocation process.
• Payment channel is "busy" while someone is performing a continuous payment. To make another payment, another payment channel must be prepared upfront.

Impulse Community Hazard

Impulse requires a system of well-known Operators which creates a small club of players. While, each individual player can not do much damage, it is easy to destroy trust in each Operator by stealing their co-signing key. Once the Operator's key leaks, some apps will continue trusting it and thus will become instantly victims of double-spend attacks, while other apps must follow an automatic protocol of revoking trust in Operator should the key be leaked.

Revocation could be done automatically by detecting double-spended transactions signed off by the Operator's key. Yet, re-adding a key is either a slow and manual process, or automatic, but then the problem is shifted one level up, to the "master signing keys" that can also be compromised.

The problem is solvable in principle, but requires a careful key-distribution protocol and secure key storage at its root. Attack on Operator makes a lot of applications either automatically vulnerable, or automatically stopped.

@kanzure: According to jgarzik points, my guess is that change uses a different p2sh address ("Each party in a payment channel generates a new keypair. ie. the Operator key is always different...").
Not doing so would be like promoting address reuse.

@kazure that can be another P2SH, of course, but with one of the keys provided by the Operator.

Note: @petertodd describes hub-and-spoke scheme here: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06576.html

I believe you have re-invented greenaddress.

Doesn't that make the Operator a co-conspirator in the eyes of the law when the government inevitably criminalizes transactional freedom?

This is a great, however many are correct that this basically reinvents greenaddress. However, this protocol is readily usable by current payment processors, and has its own merit to stand upon. Great work!

To mitigate against the risks associated with theft of the operator's key in a 2-of-2 setup, would it be possible to implement this in a 3-of-3 configuration so the operator could distribute two signing keys working in concert, which could still create a trusted transaction, but if one key were compromised, locktime would save a user's funds rather than the funds being susceptible to double-spend?

@abrkn yes.
Impulse has nevertheless the ambition to become the open way of working like in Greenaddress but not necessarily with Greenaddress as a third party for instant confirmation payments provided that this third party acts following the protocol correctly.

@petertodd The reason why Bitpay or @jgarzik are not mentioning anywhere Greenaddress should be clear. They are trying to compete in becoming the trusted third party in instant confirmation payments.

I personally think they have chances to succeed in the mid term and I think we hopefully have many trusted third parties for instant confirmation. I thank them for giving the chance to the community to compete as well building an open protocol by which anyone with the right skills can write a good client or become an other trusted third party.

Greenaddress has given on its part demonstration of being a reliable third party for on chain instant confirmation for at least one year today (and they are the only one) with no double spends detected and their skills go well beyond that. As far as returning to the community in terms of open specification is concerned they have written the specification by which a merchant knows which third party is vouching the instant payment through an extension of BIP70.
https://github.com/greenaddress/bips/blob/bip-payment-request-instant-confirmations/bip-payment-request-instant-confirmations.mediawiki

We took this concept and expanded to eliminate trust on any of the parties involved using multisigs, timelocks and third party funds as collateral. Here is the idea:
https://github.com/baleato/bitcoin-hackathon/