Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Impulse Review

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

image

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.

@jgarzik

This comment has been minimized.

Copy link

@jgarzik jgarzik commented Jan 22, 2015

  • Just like current system, Payer generates trusts Operator to provide a correct TX output (via BIP70)
  • Similarly, the 3rd party Recipient must trust that Payer and Operator will receive & agree upon a correct TX output properly directing funds to the Recipient.
  • Each party in a payment channel generates a new keypair. ie. the Operator key is always different. Thus the problem is shifting to another level (as you note).
  • It is very powerful that funds go straight to 3rd party. Operator does not hold funds; this mitigates not only Operator theft risk but also Operator compromise risk. It reduces legal liability and many other attributes.
  • This scheme is a net improvement over current payment processing, where Payer sends funds directly to Operator, who is trusted to provide proper TX outputs and also route funds eventually to the proper Recipient.
  • Community hazard can be mitigated in theory with a system of auditable oracles. It's more complex, but doable.
@oleganza

This comment has been minimized.

Copy link
Owner Author

@oleganza oleganza commented Jan 22, 2015

Thanks, @jgarzik.

  • I did not assume trust in Operator to provide a correct tx output. It might be done so in some applications, but not necessarily. Generally speaking, Operator signs off whatever tx output Payer wants. This allows putting less trust in Operator where possible and having ability to spend coins to arbitrary addresses and payment requests (bip70) that user's wallet authenticates, regardless of whether the Recipient supports or not the Impulse protocol.
  • "funds go straight to 3rd party", — yep. Only "change" goes to re-open another paychan. I mentioned this in point 2 in "pros" list. Probably should stress it better.
  • on "net improvement" — true for your example, but the example is almost irrelevant. Most cases when money is processed by Bitpay/Coinbase are caused either by lack of infrastructure on Recipient's side and/or by desire to convert coins to fiat. I see this scheme as an improvement to untrusted unconfirmed txs with different tradeoffs (such as a hazard that many apps relying on trusting these unconfirmed txs can be paralyzed or fooled when Operator is compromised). Currently unconfirmed txs are not trusted, but there is also no single attack vector to DoS the entire ecosystem.
  • Yep, we can automate a lot here, but then we still rely on having root keys locked down to avoid massive DoS of everyone trusting certain Operator or having funds locked with him. That's a mountain of Complex unfolding in front of us.

That said, I really like how Impulse combines several good ideas in a one quite elegant scheme, but it's still not optimal in terms of scalability and security. I'm working on my own idea of a decentralized clearing network and taking into account all pros/cons of Impulse. Will share when it's more-or-less complete.

@jgarzik

This comment has been minimized.

Copy link

@jgarzik jgarzik commented Jan 22, 2015

@oleganza From a holistic perspective, it upgrades everyone's payment processing security today, and creates a protocol that can be used in an even more trustless fashion tomorrow.

@justusranvier

This comment has been minimized.

Copy link

@justusranvier justusranvier commented Jan 22, 2015

Surely the privacy implications are worth mentioning in the con section?

The Operator by definition tracks the spending behaviour of the Payer which puts it in possession of information which it has an incentive to sell to third parties.

@oleganza

This comment has been minimized.

Copy link
Owner Author

@oleganza oleganza commented Jan 22, 2015

@jastusranvier not necessarily. User's wallet may receive Payment Request directly from Recipient and then ask Operator to sign off his transaction. The only privacy implication is that Operator and everyone else now can distinguish change outputs from payment outputs and therefore somewhat estimate amount of cash in your pocket. But you can mitigate that by having several independent paychans and, in general, having smallish amount in the whole scheme.

@oleganza

This comment has been minimized.

Copy link
Owner Author

@oleganza oleganza commented Jan 22, 2015

Additionally, if the payment P2SH address is also 2-of-2 multisig (where both keys belong to the Recipient), then no one except for Operator knows which is change and which is not. So if Recipient wants to be nice to the user, they could have their deposit addresses mimic paychan addresses.

PS. If Recipients need to use 2-of-3 funding transaction, then paychan can be open with 2-of-3 too with dummy 3rd pubkey which is provably random for Operator and Payer, but looks like normal key for everyone else.

@petertodd

This comment has been minimized.

Copy link

@petertodd petertodd commented Jan 22, 2015

You realise this is almost exactly how @greenaddress works, minus the useful feature that newly deposited funds can't be immediately spent with zeroconf guarantees, unlike greenaddress? The Impulse protocol spec should be referencing them as prior art.

Why did BitPay go down this inefficient route rather than a proper hub-and-spoke micropayment scheme? (as I thought Impulse was; my mistake) You have all the privacy issues of involving a third party, with zero benefits beyond zeroconf guarantees. (edit: and slightly smaller txs in cases where all receivers of funds are willing to trust BitPay for long periods of time and txouts can be combined)

re: Zeroconf, implementing replace-by-fee scorched earth would give better privacy and remove the need for a central point of failure.

@kanzure

This comment has been minimized.

Copy link

@kanzure kanzure commented Jan 22, 2015

Are those change outputs going back to the same P2SH address? And why not a different P2SH address?

@LaurentMT

This comment has been minimized.

Copy link

@LaurentMT LaurentMT commented Jan 22, 2015

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

@oleganza

This comment has been minimized.

Copy link
Owner Author

@oleganza oleganza commented Jan 22, 2015

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

@oleganza

This comment has been minimized.

Copy link
Owner Author

@oleganza oleganza commented Jan 22, 2015

@abrkn

This comment has been minimized.

Copy link

@abrkn abrkn commented Jan 22, 2015

I believe you have re-invented greenaddress.

@Azulan

This comment has been minimized.

Copy link

@Azulan Azulan commented Jan 23, 2015

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

@smcki012

This comment has been minimized.

Copy link

@smcki012 smcki012 commented Jan 23, 2015

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!

@Dave-Aiello

This comment has been minimized.

Copy link

@Dave-Aiello Dave-Aiello commented Jan 23, 2015

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?

@gabridome

This comment has been minimized.

Copy link

@gabridome gabridome commented Jan 27, 2015

@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

@sebaslogen

This comment has been minimized.

Copy link

@sebaslogen sebaslogen commented Feb 2, 2015

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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.