(That's my attempt to understand what problem Impulse solves and how. I am not a designer/developer of this scheme.)
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 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.
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 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.
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?