Exchanging pubkeys for multisig | Bitcointalksearch.org

Mike Hearn

legendary

Activity: 1526

Merit: 1134

Quote from: waxwing on October 28, 2013, 01:37:56 PM

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.

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: kjj on October 28, 2013, 11:04:40 AM

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

waxwing

sr. member

Activity: 469

Merit: 253

Quote from: Mike Hearn on October 28, 2013, 11:55:38 AM

Quote from: waxwing on October 28, 2013, 05:46:14 AM

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:

Quote

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.

Quote

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

Mike Hearn

legendary

Activity: 1526

Merit: 1134

Quote from: waxwing on October 28, 2013, 05:46:14 AM

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.

kjj

legendary

Activity: 1302

Merit: 1026

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.

waxwing

sr. member

Activity: 469

Merit: 253

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

Topic: Exchanging pubkeys for multisig (Read 826 times)