Topic: Multi-signature transaction interface suggestions - page 2. (Read 2823 times)

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

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.

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. 

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.

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

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.

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.