Exchanging pubkeys for multisig

[waxwing]

I know a lot of effort went into making a useable interface for Bitcoin's internal key manipulations from the beginning - e.g. base 58 encoding to create strings that wouldn't upset client software or users.

But how about the escrow type transactions with multisig? I'm trying to implement this right now, and I realise that I don't know of a way to avoid users having to share their raw public keys.

What would be the most sensible way to implement this sharing, while keeping it as safe and non-technical as possible for users? Very long hex strings seem like a bad option, but are there any others? Anything better than just putting it in a file?

Edited: the same question may apply to signatures (I think I got that right - parties need to send/share both pubkeys (for address creation) and signatures (for redemption)).

[1715501155]

1715501155

[kjj]

To create a P2SH multisig address, some entity in the process must be in possession of all pubkeys.  Pubkeys are generally considered safe to share, publish, etc.  That's why they are called public keys.

WIF works perfectly well for keys used in multisig.  You can import all of the keys into the client if you want, or you can specify them in the RPC signrawtransaction call, and whatever infrastructure you create to support your system had better be able to read them too.

When redeeming, signatures are also safe to ship around.  Signatures are big, coding them in base58 makes them bigger.  No one is going to be processing them by hand.  Signature problems will just show up as an invalid signature, and they can find the problem and try again.  It isn't like a key or an address where an error can drop coins into a black hole.

Look at BIP 10.  It is about shipping signatures around for multi-party transactions, but it looks like it would work perfectly well for P2SH multisig too.

[Mike Hearn]

But how about the escrow type transactions with multisig? I'm trying to implement this right now, and I realise that I don't know of a way to avoid users having to share their raw public keys.

Then you aren't designing it right. You obviously never want users to have to manually manipulate keys or expose in the UI "multisig" as a thing.

By "escrow" do you mean dispute mediation?

  https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

If so then you would build it on top of the payment protocol, and define messages passed between client, server and mediator that contain the necessary keys. The user would just see in the UI the name/logo of mediators acceptable to the merchant and have the ability to pick one, along with a button they can push to start a dispute.

[waxwing]

But how about the escrow type transactions with multisig? I'm trying to implement this right now, and I realise that I don't know of a way to avoid users having to share their raw public keys.

Then you aren't designing it right. You obviously never want users to have to manually manipulate keys or expose in the UI "multisig" as a thing.

By "escrow" do you mean dispute mediation?

  https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

Yes, I do, and I absolutely agree that we don't want to expose keys to the user - that was my point. In the link you provided, it says:

2.  Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).

That's exactly the step I'm wondering about.

If so then you would build it on top of the payment protocol, and define messages passed between client, server and mediator that contain the necessary keys. The user would just see in the UI the name/logo of mediators acceptable to the merchant and have the ability to pick one, along with a button they can push to start a dispute.

Yes, I agree that it works OK with a messaging system underneath. I guess my question doesn't ultimately make much sense - should we hide keys? Yes. How do we do it? The most appropriate way

[waxwing]

To create a P2SH multisig address, some entity in the process must be in possession of all pubkeys.  Pubkeys are generally considered safe to share, publish, etc.  That's why they are called public keys.

Yes, I do understand that, I was just wondering if there was something that I was missing in terms of the right format/way to exchange. It was kind of a stupid question...

[Mike Hearn]

Yes, I agree that it works OK with a messaging system underneath. I guess my question doesn't ultimately make much sense - should we hide keys? Yes. How do we do it? The most appropriate way

Right, pretty much

You could try prototyping with Bitcoin-Qt and the payment protocol implementation there. Alternatively, bitcoinj is about to get a payment protocol implementation too (there's one being prepared for review), and there's a GUI wallet template app as part of the source now that's reasonable nice looking, which is designed for contracts work.

If you're going to make dispute mediation real (please do!!!) then the right place to start is by figuring out what you want the UI to look like. Then work backwards from that to how to implement the messaging and then you'll find the multisig part is really the most trivial part of all If you do it with bitcoinj I can give you a general gist of it.