Bitcoin idea: Temporary notarized wallets – Secure zero-confirmation payments using temporary notarized P2SH multisignature wallets

One of the current problems with Bitcoin in physical commerce (payments in stores) is that due to how it solves the doublespend problem, which other decentralized digital currencies have had major issues with, means that unverified transactions are verified on average every 10 minutes through being included in the blockchain. Before a transaction is included in the blockchain it isn’t yet set in stone, and might not end up verified. That means that for transactions over a few dollars where you want to be able to finish the transaction in just seconds, the seller end up having to accept a transaction that where the buyer has a chance of invalidating your payment through pulling of a doublespend within that timeframe of up to 10 minutes on average, since nothing stops him from creating dozens of more transactions spending the same money up until one of them is included in the blockchain.

To be able to process transactions faster and not have to risk having the payment invalidated through the buyer trying to spend the same money in multiple places, some are relying on “green addresses”, which essentially are centralized services that hold the money of the users for them and imitates banks and credit card companies. They are trusted to not sign multiple transactions trying to spend the same money. This requires that you trust these companies to keep your money secure from hackers, and that they won’t run away with them or put restrictions on how you can use it.

Fortunately that’s a problem that also can be avoided using some of Bitcoin’s lesser known features. Bitcoin already supports multisignature payments (multisig transactions) where the transaction only is valid if for example 2 of 3 chosen people have cryptographically signed the transaction. It also supports something called P2SH addresses. Normal addresses are just hashes of public keys from ECDSA sep256k1 cryptographic keypairs, and spending from a normal address requires creating a valid signature of the transaction using the private key that belongs to the public keys. That proves you have the authority to spend the coins. But P2SH addresses are hashes of scripts (“pay to script hash”), which means that to spend money from them you have to provide an input to the script in question that the script accepts, otherwise it’s invalid and won’t be accepted. One example could be to create a script that accepts payouts only to certain addresses, meaning that you only can issue payments from that P2SH address to those specific predetermined addresses. Another thing you can do is to set time limits, so that the coins can’t be spent until a certain time has passed. You can also do far more advanced things, but I won’t go into that now.

So how would we use P2SH to solve the zero-confirmation problem without trusting others with our money? You can do it by reducing the the “green address” companies to notaries. You can create a P2SH address created from a script that for the next 24 hours ONLY allows you to spend money from it if you AND a trusted notary have signed the transaction. After that period you can always send it back to your regular wallet without a signature from the notary (and this means that your money won’t be lost if the notary suddenly closes shop).

The notaries replaces green addresses, and the only job they have to do is to keep track of what transactions they have signed, and only sign transactions that attempts to spend money that no previous transaction has tried to spend.

Now, within that time frame, the merchants can see that the transactions have been signed by a trusted notary, which means they can be confident that NO OTHER transaction will be signed before the first transaction is set in stone in the blockchain, and thus the doublespend problem is essentially eliminated.

Proving that a notary is malicious is trivial – you only need to keep the transactions sent to you, and if one is invalidated to a doublespend it means that they signed two transactions claiming the same money, and then all you have to do is to show the world the two transactions at once with the two valid signatures from that one notary. From that point on the notary will no longer be trusted, and a subscription service that all merchants and clients use could distribute this proof of malice across the globe in seconds, which makes it nearly impossible for a notary to profit from malice through doublespends.

All a user have to do to create such a P2SH address is to use a wallet client that can create it from a template script, where the user only has to tell the client how much money they want to send to the temporary notarized wallet. If the merchant for some reason would only trust notaries that you haven’t listed in your wallet client, you could simply tell your wallet client to use it through scanning a Qr code as you enter the store (which still means it’s only two simple steps, scan the code and enter a sum of money), which works perfectly fine if you know you’re going to be in there for about 10 minutes or more as the transaction to your temporary notarized wallet likely will be set in stone before you go to pay for the goods. In supermarkets and similiar settings, many merchants could agree on the same list of notaries, so you could create this temporary wallet in advance or right away as you enter the building. And the best of all is that the users aren’t put at significant risk if the notary would be malicious, as the worst they can do is to refuse to sign your transactions for that 24 hour period. You’ll still be able to spend your money as usual afterwards.

The discussion threads on Reddit and Bitcointalk:

Update: There’s a new service that implements a variant of this. is a wallet service that uses multisignature P2SH addresses (based on a deterministic seed for improved privacy), and which offers automatic nLockTime expiration for the multisig requirement for your coins, so that even if the service goes down you can recover your coins. Not exactly what I envisioned, but quite close (I would prefer to have a wallet that allow you to select what notary service to use).

Edited 2015-01-28: This scheme has now been improved upon by others in a version using two chained 2-of-2 multisignature transactions using collateral to assure the risk for the merchant is minimized (although this scheme is currently at risk of transaction malleability that could invalidate the collateral transaction, but hopefully that will be fixed sometime soon).


Edited 2020-11-09: found another related older post, a reference to “time limited transactions”; here Bytecoin describes a transaction that only can be claimed by the recipient until a later time when the block number reaches a certain value, after that the payer can take it back if not yet redeemed.

    • Jack
    • June 10th, 2014

    I’m a few months behind you on this, but sounds like we are on the same page. I posted a thread on bitcointalk, and someone there informed my about .

    I don’t quite understand how is doing the expiration with nLockTime (as I thought that parameter indicates a point in time after which a transaction becomes valid not invalid), but I guess I can figure that out.

    Ideally we could have merchants that have systems that work with multiple ‘notaries’ as you sort of suggest. Just like today they merchants use ‘visa’ and ‘mastercard’, but potentially there would be more such notaries. As long as I am also using one of those notaries then we can do the 0 conf dance.

    • I’m not entirely sure how it is implemented, I haven’t looked all that closely at the scripts in use, but since they provide a presigned transaction you can use after the expiration for recovery (they link to a tool and a guide for how to use this data to perform the recovery of the coins), I suspect that transaction sends the coins to a separate P2SH address which is the timelocked one. I’m not sure, but maybe that would allow you to attempt a doublespend in a way that keeps your coins temporarily locked up. If you can’t set a too short expiration time, the delay in being able to respend the coins could itself be a useful deterrant against doublespending.

      Ideally the scripting language should allow for defining more detailed requirements to be able to spend.

  1. Natanael:
    Thank you for posting this summary. I have benefitted from it.
    This business logic, hosted on the blockchain, is exactly the sort of service that the Married Wallets standard would support.
    However, the standard would allow some P2SH business logic applied to an entire wallet, and some additional security measures for individual transactions.
    Have you had a chance to review the design notes?!msg/bitcoinj/Uxl-z40OLuQ/HDBhNAtLXdQJ
    I also have some questions about P2SH, if you would be willing to answer them.

    • I have read through some of it, but I’m not an expert on the low level implementation details. Since I don’t have much programming experience I do better with high level concepts. I wouldn’t really know how to handle all the fringe cases or how to optimize for performance, etc.

    • Marius
    • August 2nd, 2014

    I think this is a very interesting concept. I am very excited. I want to ask you Natanael though, did you come up with this? i dont think you can come up with something if you dont know the lower level details and the past experience in the domain? but that hypothesis is testable though, some more cases are needed though.

    • It’s a of combination several previous ideas, with some improvements, which I came up with. Might not have been the first to think of it, but haven’t seen this specifically described elsewhere earlier. Green addresses based on hosted wallets, multisignature transactions of various kinds, timelock wills, etc. I figured that could be combinated this way to reduce the need of trust in the server. I’ve got a good grasp on how computers work and what can be done with algorithms, just don’t have much practical experience programming or any formal education in it.

  2. thank you Natanael – very interesting. Especially the last sentence in the update – is this notary service a specialized gateway node (=a service business that serves merchants and payment gateways) or a feature that is built in the wallet-end-node.

    • I’d say both. The end-user wallets would need to communicate with it to get transactions signed, and merchants would usually need to communicate with it to verify the signatures.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: