Pages:
Author

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

donator
Activity: 1218
Merit: 1079
Gerald Davis
December 01, 2011, 09:35:28 PM
#74
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?

Each private key can contains as many bits as the unified private key.  The entropy of each private key depends on the method used by the creator.  Even if one key is weaker due to flawed implementation it is still stronger than a single key because you will need all the sub-keys to construct the unified private key.
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 01, 2011, 08:48:27 PM
#73
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?
sr. member
Activity: 322
Merit: 251
FirstBits: 168Bc
December 01, 2011, 08:40:29 PM
#72
Hey guys, thanks for all the input, particularly the http://www.certicom.com links. I intend to come up with a bunch of baby-step examples, perhaps over the weekend, that hopefully my mother could follow.

I once studied abstract algebra, so this isn't totally foreign to me, but I'd prefer to read (python) code rather than latek math notation, if anyone wants to donate some code to the cause.
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 01, 2011, 08:03:32 PM
#71
Holo's are cheap if you order a ton of them, it's the setup that costs so much.
hero member
Activity: 533
Merit: 501
December 01, 2011, 07:19:34 PM
#70
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.

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.

Yep, and I can see why you charge the price you do for your coins. The holograms are more expensive than the metal by far. Since I have to do a double sided my bills may out cost you coins. I might have to consider some super adhesive cheap alternative backing to prevent scanning through the reverse side of the bill. Otherwise I might just have to switch to coins or plastic.

Edit : Maybe Gorilla Tape. It would be a pain to work with though. I can see my wife coming into the garage while I am working and me being on the floor with Ron Paul bills stuck all over me.
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
December 01, 2011, 06:17:42 PM
#69
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.

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.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
December 01, 2011, 06:12:25 PM
#68
Mike knows exactly how to do this - he did it in the example above to prove the concept.

So you two should get together!
hero member
Activity: 533
Merit: 501
December 01, 2011, 06:00:12 PM
#67
Can anyone write up a simple python module for handling this?

I am guessing it would have two methods:
def combinePublic(pubA, pubB):
   //Person A creates a public address and private key. He gives the public address (pubA) to Person B
   //Person B creates a public address (pubB) and private key
   do some magic and return pubC


def combinePriv(privA, privB):
   //do basically the same with private keys (this should create the priv key for pubC)
   do some magic and return privC

It might be something that can all be done with one method. I am willing to admit I am way out of my depth though.

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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 01, 2011, 01:11:10 PM
#66
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.

And damaged rep and others can verify she hasn't paid.  There is no way to ensure a thief can't kill a payment without a human third party arbitrator.  Still I think that is somewhat unlikely.  Alice has the goods she gains nothing by witholding payment however she risks damaging her rep so it is a net loss to withhold payment.  If you are that concerned about that event then a true escrow w/ arbitrator is the only secure method but even that isn't a guarantee the human making the decision could either side against you or could be in collusion w/ Alice.  Undecided
hero member
Activity: 742
Merit: 500
December 01, 2011, 12:55:13 PM
#65
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.
I like it!  Reading stuff like this makes me want to delve deep into EC math, but I just don't have the time.

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.
vip
Activity: 447
Merit: 258
December 01, 2011, 12:22:41 PM
#64
partially-provable reputations.

I originally meant that observers have no way to verify that Bob sent the goods.  However, I realized last night that Alice publishing 'a' implies that she received the goods and therefore that Bob sent them.  If Bob's goods happened to be reversible, such as a PayPal payment, he could chargeback later, so I suppose it's still only partially provable in that case.

As BTCurious mentions, a signature mechanism is necessary to make sure the Alice and Bob in the transaction you watched are the same Alice and Bob you think they are.
hero member
Activity: 714
Merit: 504
^SEM img of Si wafer edge, scanned 2012-3-12.
December 01, 2011, 02:09:04 AM
#63
Yeah, that would work pretty well, and can actually be done right now.
With the new changes (BIP0011) it will also be possible to include a 3rd party, who can give the coins to either A or B in a dispute.

partially-provable reputations
When coin-picking is implemented in most wallets, reputations can be proven fully, by sending from address X, where address X is well-known as being a reliable trader. Alternatively, during negotiations, one can just sign a message with his well known address' key, and the counterparty can verify that that's actually this guy. This can be done right now with 0.5 I think.
donator
Activity: 1218
Merit: 1079
Gerald Davis
December 01, 2011, 12:33:08 AM
#62
mndrix I like it.   Clever use of partial keys. 
vip
Activity: 447
Merit: 258
November 30, 2011, 07:50:38 PM
#61
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.
hero member
Activity: 742
Merit: 500
November 30, 2011, 05:25:04 PM
#60
This is interesting.  Anything that reduces the amount of trust required is good IMO.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
November 30, 2011, 04:54:05 PM
#59
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.
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
November 30, 2011, 04:53:28 PM
#58
Here is my explaination from another thread:

1) Make the bar or paper bill 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) Put the firstbits of the public key address on the outside of the first hologram
5) Ship the item along with the actual public key to the second party
6) Second party puts the second hologram on the item
7) Second private key in mini private key format under the second hologram
8. Firstbits of the second public key address on the outside of the hologram
9) NOW the second party verifies the public key shipped with the item with the public key address on the first hologram
10) then adds the two public keys together, creating the final public key
11) From the final public key calculate the final public key address
12) This final public key adddress is etched/printed on the item.
13) The BTC funds are transmitted to the final public key address

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.




full member
Activity: 154
Merit: 102
Bitcoin!
November 30, 2011, 11:30:35 AM
#57
Here is some sample code I tried (C# using BouncyCastle).  Math works as advertised.
Anyone know of a library like BouncyCastle for PHP?
legendary
Activity: 2646
Merit: 1137
All paid signature campaigns should be banned.
November 30, 2011, 11:23:15 AM
#56
I can't believe that with all my yammerings all over this board that I have just now only cracked 200 posts.  This makes me really appreciate the hard work and dedication of people like DeathAndTaxes who are over 2000!
hero member
Activity: 714
Merit: 504
^SEM img of Si wafer edge, scanned 2012-3-12.
November 30, 2011, 11:06:27 AM
#55
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)
I know you don't have this question anymore, but I would like to mention the standards document for EC cryptography: http://www.secg.org/collateral/sec1_final.pdf
It is written very understandably for a standards document. All the mathematical basics are in chapter 2. Ignore all paragraphs about F2m, bitcoin doesn't use that.
Pages:
Jump to: