Topic: Multi-signature user interface (Read 2369 times)

Let me see if I understood the (linked wallets).

1- I create 3 wallets
2- Will be 2 of 3 to spend.

So I create a wallet on blockchain.info service. A wallet on mobile app and an offline wallet on Armory.
Will be possible to on all addresses that I generate on any of the 3 wallets, only be able to be spent with 2 of 3?

If yes, I think is the perfect security solution.

I think the question is for something like BitMit, why would you ever accept being locked into a one-size-fits-all mediator like that? Nothing stops BitMit becoming a mediator and competing, but when the infrastructure exists I'd prefer a choice.

Multi-signature for voiding double-spend risk is a useful thing for sure and makes sense to include in wallets IMHO, but again, it's something that should be handled transparently via the payment protocol - wallets compare the outputs they have to the list of accepting single-spenders to find a match.

Gavin,

I apologize I haven't been keeping up at all with the payment protocol discussion.  I didn't realize it was intended to be used for inter-party/device communication for multi-sig transactions -- I thought it was basically an extension of PKI so that payment addresses can be secured/authenticated.  For instance, one of the things BIP 10 needs is not only to transmit the transaction to be signed, but also all supporting transactions bundled with it, so that the device can verify the transaction fee.  Is this in scope for the payment protocol?  Regardless, I guess I have some reading to do!

And here's an example of 2-of-2 on testnet: https://people.xiph.org/~greg/escrowexample.txt

https://gist.github.com/3966071

That is an example of multisig and offline signing.  Gavin wrote it up when we were testing the signrawtransaction fix.  I believe it is 2of3 only, but 2of2 is easy enough to figure out from it.

I r super-idiots: would you be so kind as to walk me through generating a 2 of 2 and then a 2 of three? I don't want to buy anything but walking me through doing a 2 of 2 and 2 of 3 would accelerate my learning significantly.

This is essentially M of N sigs, right? Why not in that case have set of fields for input of pubkeys the user's willing to privilege on the transaction, and a dropdown for how many of those sigs will be required to validate transaction?

The payment protocol (or a simple extension of it) is intended to be that more-flexible, standardized protocol.


Excellent!

For reference, Armory's new wallet format (and interface/GUI that uses it) will eventually implement this.  I'm hoping something will be available in the next couple months.  Multi-party transactions are quite a ways down the road, but linked/paired wallets will be implemented right away with the new version.  And with a nice pleasant interface, in the same spirit as Armory's offline transactions (in fact, it can/will use the same protocol for communicating transactions between wallets as it does for offline transactions -- which are really just a 1-of-1 tx being created by a non-inclusive party).

EDIT:  the part about "same protocol" is not entirely true:  BIP 10 was created for Armory offline, with the intention of supporting OP_EVAL (yeah, long time ago).  But it needs to be updated to be more flexible...and hopefully standardized, too.  Hopefully, the devs of other applications will be more interested in helping develop it, now that this kind of functionality is closer to actually being usable.

For more advanced things like "escrow", it's going to take some time work out how to do it "right".  For now, it will probably be a super-advanced interface that consists of a bunch of atomic operations that advanced users can piece together to do what they want, and then me & others can use the experience to optimize it make it better (such as creating a simple direct-connect protocol that executes all the operations and checks under-the-hood).  There's a lot of discussion about it in this thread where Gavin and I talked about how to do buyer-seller escrow without a third party (but easily accommodate a third party if they wants dispute mediation).  The idea is that both parties commit an extra X% to the transaction that they get back at the end, as a "risk deposit" so that the buyer knows the seller is serious, and the seller knows the buyer has incentive to finish the transaction.  And the deposit can simultaneously serve as a fee if there is a third-party and they are needed for mediation.

I'm going to be focusing on the linked wallets first: if Z is a full wallet and Z' is a watching-only/observer wallet, then you would have something like computer with AB' and smartphone with A'B, and all addresses they produce are multi-sig using P2SH, and all the multi-sig details are hidden under the hood.  Or you would have something like three owners of a company using ABC', AB'C and A'BC to control funds of a company in a 2-of-3 tx.  That is top priority.  And then I'll have all the multi-sig support in place to start experimenting with an interface for the other types.

It doesn't look like anyone else is working on this kind of interface, yet.  I guess you can expect Armory to be the first.  Should definitely be done within the next 3 months (for linked wallets).

No, there is a couple of important differences.

First, everything is configured and agreed upon outside of wallet software. Wallet software is used to approve or reject payment, and it only needs to show some details of this payment.

This makes a lot of difference: since it is external, it can be very flexible, i.e. UI will be tailored for a particular case. Also, wallet software can be relatively simple, it doesn't need to have a list of dispute mediators, for example.

I'll give you an example: if you buy something via bitmit, bitmit is the dispute mediator, there are no other options, there is no third party. You simply get a payment URL from bitmit, which will send your money to 2-of-2 multi-sig address. It would require 2 signatures to unblock: your and Bitmit's.

However, some independent shop can use third-party mediator, thus you'll need 2-of-3 multi-sig and UI is considerably different, now mediator needs to be agreed upon.

Another use case is instant payments. Suppose there is a company which is sort of a instant payment operator, let's call it bit-pay. User can pre-fill his bit-pay account, sending it to 2-of-2 multisig address. Now suppose he wants to pay to a merchant which trusts bit-pay. Payment can go without any delay because merchant will trust bit-pay's signature. (I.e. merchant trusts that bit-pay won't double-spend.)

The thing is that if wallet UI is not specific to dispute mediation it's possible to do everything with a single UI, so user won't need many different clients and whatnot.


I would not call it "mediated disputes", in my view it's more like user deposits money into his account within some services, but service doesn't have full access to that money.

Oracles might be good for individual bets, but a service can aggregate them.

For example, it might function as a prediction market, where you have current price and you can close your position whenever you want. That's quite a bit more advanced than personal bets.


Yeah, I think FX volatility hedges is an important use case. You can do that with icbit.se futures, but you need to deposit your bitcoins unconditionally, which is unacceptable in terms of risk.

It appears that the devs don't want to encourage development of multisig transactions until a convention is established. Otherwise we might end up with various approaches that end up confusing the end user. The payment protocol seems to be the priority that will establish a secure transaction that will in turn provide standardized options within the Bitcoin protocol. This is great, but there are other means to establish a secure transaction other than through security certificates. If users don't need to make the "deal" online for instance, then only the means of payment needs to be developed. This is where a skeletal multisig GUI would be useful. As an example: selling art on craigslist could be done by escrow with craigslist's messaging system. In fact, it would be a great feature to add to CL itself.

I haven't found a good one yet, but I'd really like it. I sold something to a user on this forum, and I walked him through using the Bitcoin-Qt debug console to generate a 2-of-2 multisigaddress. And then eventually when he got the goods, I tried sending him a transaction to sign and he couldn't get it to sign it. Eventually I walked him through doing a dumpprivkey for his key for the transaction and he sent that to me, and I managed to sign the transaction with both signatures myself. It seems like the underlying technology is there and just needs a nice UI for each side to get and share the public key, generate the multisigaddress and fund it, and both sign it over once both are happy with the transaction. Something that just uses the RPC interface for Bitcoin-Qt may be a good start, but as others have said, it needs to be done right if it's going to be done at all.

I think you just described what I just described

You can see bets as being mediated disputes, yes. Oracles may be more appropriate for that but either can be used.

I don't personally care about leveraged trading a la Bitcoinica, beyond its applicability to FX volatility hedges.

The counterparty risk with a 2 party "escrow" is based on credit worthiness. If one party is a merchant, that would naturally be pretty high and considered low risk. A customer credit can be assessed by the merchant in many ways. Either party can demand an "insurance" against default and probably should. The primary "escrow" can have insurance added by the higher risk party, while a secondary escrow can have a that same insurance amount "put up" by the lower risk party.

In the case of betting, they can agree to the counterparty escrow before placing the bet itself in escrow. A service can offer percentage rates based on things like WoT.

What's about this:

1. User visit's merchant's web site (foostore.com), orders and item. He is able to select a dispute mediator from a drop-down menu (bitmediator.com) and get HTTPS URL for this specific invoice. (https://bitmediator.com/invoice?id=31337)

2. User copy-pastes this URL into his client. Client fetches data by that URL and shows information like amount, name of mediator, name of merchant etc. This information can be trusted as long as mediator is trusted, but optionally original invoice can be signed by merchant.

3. When user confirms the payment client will send money to address provided by mediator and store all relevant information into a local file for reference.

4. Client shows a list of pending payments. Client can click them to open a form which provides an option to confirm or dispute payment.

I believe this can work for a wide range of applications, including dispute mediation and betting.

Perhaps I should elaborate on betting, it can work that way for any service which requires user's deposit. For example, leveraged trading sites like Bitcoinica become much more secure this way.

IMHO that might be more important than dispute mediation since it would be an unique advantage of Bitcoin.

Nothing stops the loser from refusing to sign unless they are getting a cut of the money. But regardless, something specialized like betting should be an independent app I think. Dispute mediation is going to be a very common need, that kind of betting isn't.

What's about the use case I've mentioned:

Suppose there is a betting service. When user makes a bet he sends his funds to 2-of-2 multisig address. When bet outcome is known funds are released (using user's and service's signatures), either back to user or to other side of the bet.

?

It think it's much better than betting web sites which require you to send them money directly. (So they can simply run away with that money, or claim it is hacked.)

It isn't hard to make a protocol which would let user to put in HTTPS address of such betting services, and it will do the rest (i.e. negotiate address, later negotiate release of funds).

OK, well I'm assuming by "user interface" you mean something relatively easy and straightforward, something acceptable to a non-expert.

I don't think escrow is useful for Bitcoin. Escrow providers hold things on behalf of somebody else. You mean dispute mediation - the mediator doesn't control or hold the funds at any point.

Yes I'd like to see that integrated with wallet software directly. It's a lot of work to do well and as the saying goes, "if it's worth doing, it's worth doing well" so I'd not much like to see a half-baked implementation. This is a large, complex project that would take a significant amount of effort, which is why it's not done yet.

For instance, you need a payment protocol to start with, because the merchant has to be able to indicate to the users wallet software

a) That the merchant supports dispute mediation
b) Which mediators the merchant finds acceptable

and that's too much data to squash into a bitcoin: URI. So we need to finish up the payment protocol work first, it enables many features beyond just this one of course.

And then when I say "which mediators" I'm glossing over a ton of detail there. Really, your wallet should provide you with a useful list of mediators, and that list should include their name, a brief description of their policies, probably a logo and a link to a website where you can learn more. The user needs to be able to indicate their consent to using a particular mediator, and then there needs to be a protocol that re-fetches the payment request but this time with a mediator selected so the requested outputs can be reformatted as appropriate, the wallet needs to contact the mediator and check that they really own the provided keys, etc. If these steps are skipped it's not secure.

Then if there's a dispute, it needs to be easy to set that up - really, the user should have a "Start dispute" button in their transactions history in their wallet and that should open up a URL provided by the mediator during the setup phase, and if the mediator sides with the user the wallet needs to know how to sign the refund transaction.

And then the software the merchants are using also needs to support all this.

And then finally once the software infrastructure is built, you actually need some mediators, with written policies so a user/merchant knows how they will respond to conflicts, and that they'll respond in reasonable timeframes and so on.

I think the right way to do this is have it be crowd-funded because implementations done in peoples spare time are likely to be lacking in many respects.

Well, I just want to see what's available right now...

One of obvious use cases is escrow. There are many possible forms of it, but I'm sure there is some overlap.

Do you think we'll need a special client for each particular application? I'd rather see some more-or-less general protocol which will be the least common denominator in terms of user interface.

E.g. suppose there is a betting service. When user makes a bet he sends his funds into escrow. When bet outcome is known funds are released, either back to user or to other side of the bet.


I already solved similar problem in p2ptrade: two users agree on transaction and then sign their inputs.

It didn't require any identity confirmation, but I think for the start bitcoin address can be a poor man's analog of identity.

I'm not sure it makes sense to see "multi signature" as a feature to expose directly to users. It's more a way to implement other features.

If you want to allow multiple people to sign for the same money (like for a company), multi-signature transactions don't make a whole lot of sense without a lot of goop around it to help you connect with/set up who should be signing, start the process of gathering signatures, etc.