Author

Topic: Adding public keys for safer exchanges (Read 1565 times)

legendary
Activity: 1288
Merit: 1076
December 31, 2011, 07:01:25 AM
#13
Multiplication would work better because it can't be undone the same way addition can be undone with subtraction. Or, if Alice and Bob committed to their keys before sharing them, this wouldn't be possible, because the thief needs to base his/her key on the other person's key.

Ok, so multiplication it is.  I'll try to improve the friendlyness of my Perl library.
vip
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 30, 2011, 05:06:18 PM
#12
This has been discussed... conclusion is that multiplication would be better than addition, because addition has a security flaw (unless both Alice and Bob commit to their keys beforehand).

The flaw is: if Bob knows Alice's public key, then instead of generating a keypair and giving Alice the public key, he generates a keypair and gives Alice the result of his public key minus Alice's public key.  Alice adds them together, sends bitcoins to the sum address, and Bob steals them because he knows the private key of the sum.

Multiplication would work better because it can't be undone the same way addition can be undone with subtraction.  Or, if Alice and Bob committed to their keys before sharing them, this wouldn't be possible, because the thief needs to base his/her key on the other person's key.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
December 30, 2011, 04:44:24 PM
#11
he was proposing a new way of doing escrow transactions, more p2p, but he didn't give any technical details though.

Grondilu just did Wink
yes but its have been know for a lot of time...

nice to know, could have been his way of telling us that we have to work some things out by ourselves ?
dunno, epic character this satoshi btw   Smiley
legendary
Activity: 1050
Merit: 1000
You are WRONG!
December 30, 2011, 04:41:27 PM
#10
This is multi-key escrow. I believe the blockchain supports it now, with current clients, although there's no GUI support. Ideally you'd use three keys: Alice's key, Bob's key, and a third-party judge's key, such that two of the keys together could release the funds. That way, an anonymous sender couldn't break his agreement and use the threat of withholding funds as leverage.
no because he have nothing to gain from it.
newbie
Activity: 43
Merit: 0
December 30, 2011, 04:39:13 PM
#9
This is multi-key escrow. I believe the blockchain supports it now, with current clients, although there's no GUI support. Ideally you'd use three keys: Alice's key, Bob's key, and a third-party judge's key, such that two of the keys together could release the funds. That way, an anonymous sender couldn't break his agreement and use the threat of withholding funds as leverage.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
December 30, 2011, 12:02:37 PM
#8
he was proposing a new way of doing escrow transactions, more p2p, but he didn't give any technical details though.

Grondilu just did Wink
yes but its have been know for a lot of time...
hero member
Activity: 630
Merit: 500
December 30, 2011, 11:58:37 AM
#7
he was proposing a new way of doing escrow transactions, more p2p, but he didn't give any technical details though.

Grondilu just did Wink
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
December 30, 2011, 10:18:07 AM
#6
Something on that line was proposed by Satoshi: https://bitcointalk.org/?topic=750

I guess it's only missing some user-friendly implementation.

wow, satoshi was on to something more in that thread...

"...Imagine someone stole something from you.  You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it?  Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too?  If they give it back, you can re-activate it..."

i can't stop imagining things based on such a feature, could be possible to have it on day in the Bitcoin software ?
he was proposing a new way of doing escrow transactions, more p2p, but he didn't give any technical details though.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
December 30, 2011, 10:02:14 AM
#5
its not diffie-hellmann. but yes it would work.
hero member
Activity: 630
Merit: 500
December 30, 2011, 09:53:30 AM
#4
Something on that line was proposed by Satoshi: https://bitcointalk.org/?topic=750

I guess it's only missing some user-friendly implementation.
legendary
Activity: 1288
Merit: 1076
December 29, 2011, 10:28:34 AM
#3
you mean a diffie hellman key exchange?

Ok I confess I don't know about that.  I'll check it out.
legendary
Activity: 1232
Merit: 1076
December 29, 2011, 10:24:18 AM
#2
you mean a diffie hellman key exchange?
legendary
Activity: 1288
Merit: 1076
December 29, 2011, 10:05:15 AM
#1
(I have few possibilities to read the bitcoin forum so maybe somebody has already thought of this and I apologize if it is the case.  If not, please feel free to continue reading Smiley  )

As you know Satoshi imagined a solution to offer some protection against moral risk in transactions.  It basically consists in special transactions whose outputs are reedemable not with one private key, but with two.  Thus it is possible for Alice to send some bitcoins to Bob so that Alice will never be able to get her bitcoins back, but Bob will not be able to get them either unless Alice finaly agrees.

I believe it is the best we can do against these kinds of risks, without using a third party.

However, it is kind of low-level since it relies on a specific feature of the bitcoin protocol.  I have no idea about how to actually do it, for instance.

I think it is possible to do exactly this with a higher level method.

So, let's assume Alice wants to sell Bob 10 BTC against 30 USD via bank wire.  Alice and Bob do not trust each other so none of them is willing to pay first.

Here is the idea.

Both Alice and Bob generate a new random bitcoin address on their computer.  Those keys are basically secret exponants in the secp256k1 elliptic curve.  They also compute the corresponding public points, which are two 256 bits numbers.

Alice:
Code:
my $key = new Bitcoin::PrivateKey label => "10BTC for Bob";
my $point = $key->public_point;
Bob:
Code:
my $key = new Bitcoin::PrivateKey label => "10BTC expected from Alice";
my $point = $key->public_point;

They both exchange their public points, on IRC for instance:

Alice>  Ok Bob, here is my public point:  435ab6e5......5f54,  b87f566......90cd
Bob>  Ok, here's mine :  123fe.....32a,   32aa54....cc54

Now they compute the sum of these points, and get the corresponding bitcoin address

Alice:
Code:
my $pointsum = EC::add $point, $bobpoint;
print new Bitcoin::Address $pointsum;

Bob:
Code:
my $pointsum = EC::add $point, $alicepoint;
print new Bitcoin::Address $pointsum;

They check they get the same bitcoin address, and then Alice sends 10 BTC to this address.

At this point, none of them is capable of reedeming those 10BTC, but obviously they can check that they are in the blockchain with bitcoinexplorer or something.

Once Bob aknowledges that the bitcoins are buried enough in the blockchain, he can initiate the 30USD bank wire.

Two or three days later, Alice aknowledges that she received the 30USD.  Now she communicates the secret exponant she generated.

Bob now knows both secret exponents.  Thus he can compute the secret exponant of the exchange key:

Code:
my $exchange_key = new Bitcoin::PrivateKey +($key + $alice_key) % secp256k1->{generator}{order};

With this key, Bob can redeem the 10BTC.

Had Alice refused to reveal the private key, Bob would have been screwed, but Alice would not get any real benefit for that, as the 10BTC would be lost in the blockchain for ever.

Am I wrong somewhere?
Jump to: