Topic: Elliptic curve math question - page 4. (Read 14001 times)

BTW, I had said earlier that I wouldn't trust this system, because then I'd have two entities who I'd have to trust not to screw up. However, this additive stuff should make it at least possible to verify each private/public pair - who screwed up. Out of curiosity, is it possible to combine many more pairs?

(privA + privB) + ... + (privY + privZ) --> (pubA + pubB) + ... + (pubY + pubZ)

And does doing so weaken the key strength? Is each component (A,B,C...Z) easier to crack than the additive result, or do they all contain just as many bits and are just as seemingly random?

Rob, have you called or e-mailed the hologram guys yet?  Each of my last two orders took 5-6 weeks.  I would be willing to co-sign.

I am asking them to quote me on some rectangular holograms that would be perfect for bills.  Regardless of what I do, you could probably do them as well.

By the way, they of course aren't the only provider of holograms in town.  But the hologram adhesive (that shows honeycombs if you sneeze on it wrong) from these guys is so good, I don't dare go anywhere else.  Many of the other samples I have played with are too easy to peel off intact.

It would be great if Mike and I could basically co-sign each other's money this way. It would add to the cost, but the user would have little doubt that either of us have the private key. The double hologram would also mean that both would need to replicated to produce a useful counterfeit.

The only problem is if Alice receives the payment and doesn't transmit a, then Alice has the goods and Bob has no funds.  Alice doesn't have the funds either, at least.  I guess if you want that level of assurance, you can use scripts.

The above discussion suggests a technique for two-party escrow without transaction scripts.

• Bob wants to sell Alice goods for Bitcoin payment.
• Alice generates key pair (a,A) and sends A to Bob.
• Bob generates key pair (b,B) and sends B to Alice.
• Alice sends payment to the address corresponding to A+B.  At this point, neither Alice nor Bob can spend the funds.
• Bob verifies payment was sent to address A+B and ships the goods to Alice.

If Alice receives the goods as expected, she sends 'a' to Bob.  He uses the private key a+b to sweep funds to his own address.  If Alice never receives the goods, she withholds a and the funds are permanently lost.  If Bob wants to refund the payment, he sends 'b' to Alice and she uses the private key a+b to sweep funds to her own address.

If the transaction goes well and all messages are public, third parties can verify that Alice fulfilled her part of the deal.  This could form an part of a p2p exchange with partially-provable reputations.

partially-provable reputations.

partially-provable reputations

Sounds good.  You are right about not being able to look up firstbits on a nonfunded account (what was I thinking?).  That is why we have peer review, right?

1) Make the item with spots for two holograms and a final public key address
2) First party gets the item
3) Put the first private key in mini private key format under the first hologram
4) Ship the item along with the actual public key to the second party
5) Second party puts the second hologram on the item
6) Second private key in mini private key format under the second hologram
7) then adds the two public keys together, creating the final public key
9) From the final public key calculate the final public key address
10) This final public key adddress is etched/printed on the item somewhere, possibly on the hologram
11) The BTC funds are transmitted to the final public key address

At this point no one could possibly know the private key since it has never even been calculated.

To redeem:

1) Pull off both stickers
2) Get the two private keys
3) At a web site that supports the two key option, enter both private keys (Mt Gox, StrongCoin, etc. could be talked into supporting this option)
4) The web sites that support this option would then simply add the two private keys together
5) You now have the private key for the combined public key address etched/printed on the item
6) Redeem the BTC from the item

The other redemption options mentioned above are also possible.

The bolded steps are incorrect.  There is no address for the two partial keys.  There is also no reason to record the two partial public keys because they can't be looked up. You can't get a firstbits of a non-existent address.

Remove/change steps 4, 8, 9 and it is a good summary.  In the redeeming section for section 4 I would indicate you have multiple options
a) use a website which supports dual private keys
b) use a standalone client designed for loading dual private keys
c) use a simple non-networked application which generates the single key from the dual private keys and use it anywhere a single private key can be used.

As for what to put print on the hologram
a) nothing
b) some serial number which could be used to lookup the partial public key (not very useful)
c) the combined public key (i.e. step 10).  This would require some pre-coordination between two parties.

A is the easiest.  B isn't too tough but doesn't provide much value. C is the best but may requires some pre-coordination.

Here is some sample code I tried (C# using BouncyCastle).  Math works as advertised.

The question is what allows you to assert.

ECC(private key 1 + private key 2) = (public key 1 + public key 2)

We know these are true:
ECC(private key 1) = public key 1
ECC(private key 2) = public key 2

But do we know (as in some whitepaper, mathematical proof, etc) that:
ECC(private key 1 + private key 2) = (public key 1 + public key 2)