Multi-signature transaction interface suggestions

[etotheipi]

I mis-read a post by Gavin thinking he was talking about how it multi-signature tx's might be used by users, and I created some mock-ups of a potential user-interface.  I am reposting in a new thread where it is more appropriate.   I am working (very slowly) on creating my own light client, though I have no anticipation of getting it done any time in the near future.  However, I already made these mock-ups, and thought they might be inspirational for other developers who might be working on the reference client or their own clients.

The complexities of multi-signature transactions will require a very polished, clean interface for less-savvy users to have a chance to use these transactions properly.  My goal is to nail down what features (buttons, options, input validation) are needed in the GUI, and also try to converge on a consistent terminology for each of the various complexities.  For instance, I have used "distribution proposal" to denote how a user might propose a Tx spend and collect signatures from the other parties.



Full-sized image is here:  http://dl.dropbox.com/u/1139081/BitcoinImg/AdvTxDialogsFiveEx.png

It would be nice to discuss the various features presented here, figure out what is missing, and kind of vet design ideas before I get to the point of actually programming the GUI. 

[etotheipi]

I don't usually bump threads because I think it's rude, but I'm doing it.  With Gavin talking about enabling multi-signature transactions, the community is going to have to start deciding how to bring them to the 99.99% of users that can't or don't want to construct them manually.  It's not very useful if no one can use it.

I'd like to figure out the CONOPS (concept-of-operations) for users that will use these transactions.   My mock-up contains a lot of ideas, but it's not the entire solution.

For instance, what is the most efficient way to execute a 2-of-3 transactions for the buyer-seller escrow case?
- Online buyer wants to purchase item for X BTC
- Buyer commits 110%*X to a 2-of-3 transaction between buyer, seller and third-party arbitrator.
- If buyer receives product and everyone is happy, buyer and seller both contribute signatures to send X to seller and 10% return to buyer (so buyer has incentive to complete the tx).
- If buyer and seller cannot agree, no one gets the money (so both parties have incentive to agreeably resolve situation).
- In event of dispute, both buyer and seller can appeal to third-party to arbitrate.  3rd party gets the 10% as fee.

This may not even be the best way to execute this kind of transaction, but it's feasible, and it will involve juggling a lot of different things.  Proposing distributions of the encumbered money, collecting signatures, serializations, constructing final tx to be broadcast, and all with an "idiot-proof" interface for users that don't understand entirely how these things work.

[matsh]

I find your work very inspiring! Just want to let you know that you aren't alone excited at the possibilities here.

[casascius]

For me, the most idiot proof scenario I can think of, is if someone starts up a website as a "security service" that holds one of the keys and performs optional secondary verification before allowing a signature for the 2nd key to be rendered, especially on high value transactions.

For the user, the secondary "security service" might release their own patched Bitcoin UI client (with source) that, in addition to the normal Bitcoin UI features, offers to automatically interact with the service for the purpose of encumbering and unencumbering bitcoins.  That patched client would ask (via RPC's etc.) for the web service to sign things with the keys it holds.  The web service would implement whatever policies were appropriate (e.g. getting an "out-of-band" confirmation from the rightful account holder via SMS) before dispensing the second signature.

[etotheipi]

Well certainly, that would be idiot-proof for the ((A and B) or C) transaction type.  However, I think users benefit a lot more if the capability is built into a "standard" client, and then the security company only has to focus on the second-factor authentication.  It would cost literally 10-100 times as much to also have to do software development, deployment, maintenance, and support for the software.  Not to mention, users would then have to juggle multiple programs just to use Bitcoin and that's not good for general acceptance.

It would be amazing to the success of Bitcoin if these features weren't too complicated to use and didn't require third-party involvement.  Perhaps a family would put a bunch of money into an account encumbered by 2-of-3 transactions between you, your wife, and your kid -- the kid can spend/withdraw the money only if at least one parent agrees, and the parents can't take the money from the kid unless they both agree.  However, these ideas may build hype and then be unrealizable because of implementation/interface details that can't be worked out. 

[casascius]

Well certainly, that would be idiot-proof for the ((A and B) or C) transaction type.  However, I think users benefit a lot more if the capability is built into a "standard" client, and then the security company only has to focus on the second-factor authentication.  It would cost literally 10-100 times as much to also have to do software development, deployment, maintenance, and support for the software.  Not to mention, users would then have to juggle multiple programs just to use Bitcoin and that's not good for general acceptance.

It would be amazing to the success of Bitcoin if these features weren't too complicated to use and didn't require third-party involvement.  Perhaps a family would put a bunch of money into an account encumbered by 2-of-3 transactions between you, your wife, and your kid -- the kid can spend/withdraw the money only if at least one parent agrees, and the parents can't take the money from the kid unless they both agree.  However, these ideas may build hype and then be unrealizable because of implementation/interface details that can't be worked out.  

If Bitcoind could be segregated such that all it did was speak P2P, had no UI, and served as a core for somebody else to write a front end wallet manager, somebody else could create a UI that favors all of the various scenarios (wallet service, wife/self/kid, escrow agent, etc.) as well as cater to all the OS's of the user's choice.  I think bitcoind should be modified so that it allows such transactions (and recognizes them as "standard"), but if the bar required to write a new Bitcoin UI could be lowered in the process, someone else could fill each of these niches without having to worry when Gavin will be able to comb through and test their code.

Of course, bitcoind is already segregated and lacks a UI, but also lacks a couple of key calls that would permit a new front end UI and wallet manager to function.  Mainly, there needs to be an RPC call to ask bitcoind for a list of all spendable transactions in the block chain, belonging to each bitcoin address in a given list (like block explorer gives today).  Secondarily, there'd need to be a way to get realtime notifications and to push signed transactions to the network, though these can be accomplished by connecting via the p2p protocol and acting like a limited peer and this could be worked around.

[etotheipi]

Here's an annoying interface detail I realized while trying to implement this:

(1) I create a "distribution proposal" for the funds -- it's an unsigned transaction
(2) I hash this object to give it a unique ID, to reference when talking to the other parties ("Hey, did you ever sign transaction 9bf3218a?")
(3) Everyone signs the tx, and it is broadcast, but the official tx ID (its hash) changes because of the signature
(4) No one actually knows what the ID will be until the packet is signed and broadcast
(5) Interested parties will have to search their own txs looking for one that hashes to 9bf3218a when you remove the sigs

Sure, step 5 can be automated to some extent, but this is annoying.  People will ultimately have to track two different IDs for the same tx.  This is crazy confusing for folks who have a questionable understanding of how Bitcoin works.  It also requires a second step:  perhaps you are trying to keep track of your transactions in a DB.  You have to update the DB once when you get the DP, and then wait until it shows up in the blockchain to update the DB again with the new hash.

How can we intuitively present these ideas to users that wish to use them?
Is it possible for the community to use consistent terminology so that it doesn't change between programs?

It may sound trivial to some, but these are details that really confuse the hell out of end-users that don't understand it like the developers do.  Users need a way to reference these transactions both before and after.  Perhaps "unsigned tx ID" and "broadcast ID."  Also, it would probably be good to use a different encoding for them.  Regular TxIDs (broadcast) are usually displayed in hex.  Perhaps "unsigned Tx ID"s can be presented in Base58 with a couple static leading characters to add some consistency across all of them.

I guess we also would benefit from coming up with a "standard" serialization process for distributing and collecting signatures.  Though, I will probably make a BIP for that...

[Gavin Andresen]

I've been thinking a lot about transaction IDs and how to gather signatures for multi-party transactions, too.

For the most part, I think all the details should normally be hidden from users-- I think "Select Transaction Type" is much too geeky.

Thinking out loud, and starting with what I think will be a very common use case:  buyer and seller and somebody to resolve disputes that arise (2-of-3 escrow).

Are you imagining all three are using a bitcoin client? In my head, one might be using bitcoin-qt, another a web-based wallet service, and the dispute resolution would be done by a company with a website. I don't think "we're all running bitcoin on our computers" will be the common case.

So here's how I see it working (my ClearCoin experience may be biasing me):

Buyer and Seller sign up with the escrow service. During signup, they each give the escrow service a public key.  How?
  -- Clunky way:  they poke a "Advanced.... New Public Key" button and then copy&paste a long string of hex
  -- Better way: they poke a link on the escrow status page that does some magic
     (maybe there's a bitcoin:sendnewpublickey?destination=https://www.clearcoin.com/newkey/user1234 URI type that can be made to Do the Right Thing)

Buyer or Seller then creates an escrow at the escrow service's website.
  -- Escrow service creates or assigns a keypair for their part of the 2-of-3
  -- Escrow service creates a newfangled bitcoin address using the 3 public keys.

Buyer sends bitcoins to the newfangled bitcoin address (by clicking on it at the escrow service's page-- it could be a bitcoin:... link)

Escrow service's wallet sees the payment to the newfangled bitcoin address, updates the status page.

Buyer tells seller they paid.  Seller checks the escrow status page, clicks on a "send me the money" link and ships the product to the buyer.

What does the "send me the money" link do?  It needs to get a signature from the seller for a transaction that spends from the 2-of-3 transaction and sends to the seller's wallet.  Another bitcoin: URI that does magical stuff?  (bitcoin:signtransaction?tx=...hex...&destination=https://www.clearcoin.com/... ) Or some other clunky copying-and-pasting of long hex strings?

Days later: Buyer gets the product and is happy. They visit the escrow status page and click on a "send THEM the money" link, which does more magical stuff. Or more clunky copying-and-pasting of hex strings.  In any case, the escrow service gets the second signature and sends the transaction to the bitcoin network, and the coins show up in the seller's wallet.

Couple of notes:

I don't see the newfangled-bitcoin-address being part of the buyer's or seller's wallet, and adding it to their wallet would be yet another step.

Need to think about what happens if the escrow service suddenly disappears... they can't steal any coins, but if neither buyer nor seller knows the public key the escrow service is using then they can't complete the transaction by themselves.  Perhaps the bitcoin: URI that the buyer uses to fund the transaction should include all the public keys and should be added to the buyer's wallet...


All of this would be much nicer if there was a more user-friendly, security-friendly representation of bitcoin addresses / public keys.

[finway]

2-of-3 signatures are useful.

Like the alipay.com in China (belong to  alibaba,  belong to yahoo) ,
when buyer and seller has disputes ,
ALIPAY will decide where the money goes (back to buyer or forward to seller, depending on evidence).

Most of China's e-commerce are using this kind of service.

[etotheipi]

I think it's a mistake to assume that users won't be using Bitcoin from their own computers.  One core attraction of Bitcoin is the decentralization, and by assuming that end-users will flock to centralized "access points," we're creating a self-fulfilling prophecy.  We won't try to make it usable by the end-user directly, and then there will have to be third-parties to dumb it down for users.

My attitude is to not concede to third-parties until we know we have to.  Polish the hell out of the interfaces, make it as intuitive as possible, and give the users a chance to manage their own money.  If a user can succeed without paying a fee to a third-party, why would he?  Obviously, the 2-of-3 escrow transactions have a third-party, by definition, but that's a different topic than whether users will be managing coins on their computer or through a service.  I think light-clients that don't download the blockchain (or take 4-48 hours to load), with encrypted wallets, will make a huge difference in usability for "regular" users.  (most regular people use online banking... why not BTC?)

Additionally, I think one of the most important things, is the ability for management at small companies to handle BTC without having to hire/divert employees to deal with it.  Any benefits of BTC seen by small companies would be overrun by the cost to maintain it.  And without companies using it, BTC won't get very much attention.

Regardless, I totally agree about hiding all this stuff behind an "Advanced" tab/menu.  I think "regular" users should be shielded from confusing themselves with complex Bitcoin operations, until they explicitly decide they want them.  

So along those lines, I'm working on a BIP right now for multi-sig exchanges, which can be handled much like PGP/GPG msgs and sigs (armored ascii, easy to copy/print/email).  I think it gives us an opportunity to standardize this process so all BTC programs can interoperate without trouble.  Maybe I'm being too optimistic...    I'll post a link to the BIP when I get it up, but right now the wiki is inaccessible

EDIT:  Btw, I'm not ignoring the rest of your post, I just wanted to throw it out there that my initial assumptions are different, and I think there's reasons to be optimistic.  I'm going to work out some more details in my head before responding.

[etotheipi]

By the way, I just posted BIP 0010 to gist:  https://gist.github.com/1321518

Unfortunately, I couldn't figure out why word-wrapping is failing, so you might have to click the "raw" link to see it rendered in plain-text with wrapping.  

Keep in mind that the entire second half of that BIP is actually pseudo-code.  So it may appear long at first glance, but it's only half of what it seems.  On that note, I saved the gist as .py so if you examine the code from the original link, it will be a little easier to read with code highlighting.

[Gavin Andresen]

RE: BIP 0010 :  Cool!

Suggestion:  if we're going to borrow PGP's file format, then we should be as compatible as possible, and reference their standards document:  http://tools.ietf.org/html/rfc2440

In particular, they use Radix64 encoding, not hex...
 

[etotheipi]

RE: BIP 0010 :  Cool!

Suggestion:  if we're going to borrow PGP's file format, then we should be as compatible as possible, and reference their standards document:  http://tools.ietf.org/html/rfc2440

In particular, they use Radix64 encoding, not hex...
 

There's not really any overlap between what we're encoding and what PGP is encoding, so I'm not sure how necessary it is.  However, I agree that Base64 encoding would result in less characters on-screen, and there may be other things to learn from PGP.  Though, if anything, I would expect Base58 would be better since any BTC software would already have a method for the conversion.  Either way, any of this is open for discussion.

The other difference is that PGP basically encodes everything into a single opaque block of Base64, whereas I'm interested in keeping a little bit of human-readable information outside of the encoding.  To someone who doesn't know/care what's between the begin/end tags, it doesn't make a difference.  But it makes a huge difference for those of us who are inclined to visually inspect these code blocks.  I envision getting an email where someone copied the TxDP into the email and said "please add second signature and broadcast."  I don't have to fiddle with any programs to know that they forgot to sign it.

So, this is temporarily in gist, but I'd really like to get it into something more like what you have here, or at least figure out how to get gist to apply some kind of reasonable formatting to it.  Perhaps someone can help with this.  Once I get it pretty'd up, I'll forward it to the btcdev mailing list.    EDIT: got converted to a "markdown" document in Gist, now it looks pretty good!  I might leave it on there for now, and duplicate it on the wiki when it's back up

[crispy]

A couple of questions which I think were touched on a little:

First, would the recommended approach be to add calls to the API?  For example, a call that allows low-level crafting of the transaction or at least the script could be used by multiple UI's so that the presentation is separated from the inner workings.

Second, the case of buyer-seller-mediator can be handled with a 2-of-3 signature transaction.  My question is: does the mediator get paid in a separate transaction?  What if the mediator expects a small fee if the transaction goes properly, and a larger one if he has to intervene?

[etotheipi]

First, would the recommended approach be to add calls to the API?  For example, a call that allows low-level crafting of the transaction or at least the script could be used by multiple UI's so that the presentation is separated from the inner workings.

What you said is essentially what I envisioned.  Any kind of multi-sig transaction can be serialized in this way, and then anyone who follows this wannabe-standard can interoperate with others who do the same.  If someone wants to set up a service for exchanging these blocks, they can, or someone can just make a client that recommends sending them inline in emails.  I just wanted to define a consistent way to circulate information that works in ASCII fields and is usable by even the most lightweight clients (no blockchain needed, to use sign it).

Second, the case of buyer-seller-mediator can be handled with a 2-of-3 signature transaction.  My question is: does the mediator get paid in a separate transaction?  What if the mediator expects a small fee if the transaction goes properly, and a larger one if he has to intervene?

I don't know if I'm at the bleeding edge of this field, but I envision that there would be a third-party service that freely gives out addresses.  The buyer will put up 110%-120% of the cost of the merchandise into the multi-sig tx, and then the buyer will get that 10% back when the transaction is complete (thus giving him incentive to finish the transaction, even after he receives the goods/service).  If something goes wrong, the buyer and/or seller can contact the third party to mediate, and the third party would get the 10%.  It's only when something goes wrong that the mediator gets involved or gets any money.

Arguably, this isn't ideal because it means the buyer is always paying for the mediator.  You could have buyer and seller both put up 5%-10%, but that would require another multi-sig tx in order to seed the transaction, in addition to the one to unlock the funds afterwards.

[casascius]

Other than preferring Base64 over hex, this is how I envision it:

Code:

----- BEGIN BITCOIN TRANSACTION -----

Funding source 1: 47cf51a4fb5f6dd6ed3169a78601e1ad10bcae27e00c7c0e126f67bb6cf06fb3:1
Funds: 0.79 BTC
Key:
 044752605d1c731161ee631c8a224cf4d90303bd8596cafc53d67b2bcc765ed302c3
 ff865acb1eabfedf202b6017b680802db19f4e1573497a76a1c2e7e2bf6625
Signature:
 3046022100b23d6df3c9c1dee438523043475ee717e2986af55c83c65730446d8bf4
 d889fd022100e34a3b4e07b06fff299ffe0c5a00f60375324d55502b2fef4f774394
 7eca107801

Funding source 2: bcd1b6acc8d5980970ad993ab57f86da7259d5c4a4816a75065544d87b5eac50:1
Funds: 0.4 BTC
Key: Unsigned
Signature: Unsigned

# Total funds: 1.19 BTC

Disbursement 1: (A AND B) OR C
A: 13y3HpqB99TSBotmrr7zstJHLvvvFQDYRE
B: 1J5TrKD3XR1bw7HxcPp2cfTW7dev1T2ZNM
C: 19jRCAkkA1vwrLqLESdbpLkBiFjbqm12kq
Funds: 1 BTC

Disbursement 2: 1LrcnDZkLKm8bZC3Hxc8aGV7na7wcPvD3C
Funds: 0.18 BTC

Authorized processing fee: 0.01 BTC

# Total disbursements: 1.19 BTC

#Comments:
# This transaction is incomplete because one or more funding sources is awaiting a signature.
# Changing the sources or disbursements will void the existing signatures.
----- END BITCOIN TRANSACTION -----

[Mike Hearn]

So, just to reiterate what I said on the mailing list, I think any UI that involves seeing something (base64,hex,base58) encoded isn't going to work.

The goal should be very simple - the user should never see any codes at all. That is the UX a professional software company would be aiming for and Bitcoin should be no different.

Gavin is on the right track - files or magic URLs that can be handled by the software the user is running are the way to go here. For escrow setup, the user should be presented with a list of escrow providers that the merchant finds acceptable and some useful data about each one (logo, name, link to their website, some promotional text, etc). Then you just select one and the rest is automatic.

[etotheipi]

The goal should be very simple - the user should never see any codes at all. That is the UX a professional software company would be aiming for and Bitcoin should be no different.

This is a higher-level implementation detail.  For someone writing a client or starting a service for helping people to do multi-sig transactions, they should implement it in such a way that the user never sees a TxDP block.  But that doesn't mean that we should ignore the use case where advanced users might actually find it useful to work with raw blocks.  The goal of BIP 0010 is provide a compact way to represent the data that should work well for all use-cases.  It's up to the client/app implementer how much they want to expose to their users..

If someone is trying to make a super-simple client for average users and it requires them to copy these code blocks around, it's not going to be very successful.  But there's no reason that BIP 0010 can't also support the advanced users that might actually prefer to copy the code blocks around, while at the same time defining an interoperable way for all users to accommodate it.  For instance, a "simple" user can send me a .txdp via email attachment without ever seeing any code because their client can create an Outlook/Thunderbird email window with the attachment already there.  I could install software to automatically detect and handle this attachment without exposing any of the code to me... or maybe I'll open the attachment myself and manually inspect and sign it with my CLI tools.  It costs us nothing to support all these use cases, and it really does support all use cases and guarantees interoperability, there's a good chance other developers will use it.

Gavin is on the right track - files or magic URLs that can be handled by the software the user is running are the way to go here. For escrow setup, the user should be presented with a list of escrow providers that the merchant finds acceptable and some useful data about each one (logo, name, link to their website, some promotional text, etc). Then you just select one and the rest is automatic. 

Again, third-parties handling these things is a higher-level implementation detail.  I really want a "standard" that is usable without a third party (even if only by advanced users) , and then the third-party services can step in to accommodate the less-advanced users.  I believe that with some kind of ASCII encoding as defined in BIP 0010 (or Cascasius' suggestion), it's possible to write client software that requires only a few steps to execute a multi-sig transaction without a third party.  It would be awesome if we succeeded at this -- and it's completely within the spirit of Bitcoin to have a system that can be usable without third-parties, even if most users will end up using one.

[etotheipi]

Other than preferring Base64 over hex, this is how I envision it:

Code:

----- BEGIN BITCOIN TRANSACTION -----

Funding source 1: 47cf51a4fb5f6dd6ed3169a78601e1ad10bcae27e00c7c0e126f67bb6cf06fb3:1
Funds: 0.79 BTC
...

Funding source 2: bcd1b6acc8d5980970ad993ab57f86da7259d5c4a4816a75065544d87b5eac50:1
Funds: 0.4 BTC
...
# Total funds: 1.19 BTC

Disbursement 1: (A AND B) OR C
...
Funds: 1 BTC
#Comments:
...
----- END BITCOIN TRANSACTION -----

Casascius, I think the number one priority for TxDPs (or whatever we want to call them) should be machine-readability.  That's not to say your suggestion is terribly difficult to parse via code, but it's definitely much more focused on human-readability--which I think should be one of the lower priorities.  I think the standard use case will be users getting this TxDP as an email attachment, and then their client will automatically detect it and display it in human-readable form anyway. 

As such, I believe that we should definitely have a format that has minimal whitespace, extra words and punctuation.  And we should definitely limit it to 80 columns to make sure that identifying and copying it by hand is super easy (I hate getting emails where text is running off the right side of the screen... it's should be a compact representation).  After these two priorities are satistified, then we should start adding stuff for human-readability for those of us that might be inclined to manually inspect it.  But I think, even for advanced users, the code blocks will usually be loaded/copied-into a program that will present the data in a pleasant, human-readable form, and thus, we should focus on ease of client implementation, not human-readability.

I believe including the TxIn amounts and a comments field is a good idea.

[casascius]

Why isn't this machine readable?  I find this very easy to parse, and would consider writing code to parse it very elementary.

All of the lines are of the following construct:

Name: Value

Parsing the block is as simple as splitting it on CR/LFs, discarding the comments, looking for a colon on each line, taking everything before the colon as name, taking the rest as value.  And if the line starts with a space, treat it as a continuation of the previous value.

Cutting and pasting text is so much safer than having people open file attachments.