It doesn't hurt, but I'm not sure how much it helps.  The multiplication scheme (DHSS) is used all the time with with pre-published, persistent identities/keys on the internet, all the time.  I think the point here, was, that DHSS is established and you can feel comfortable using it in the ways prescribed by NIST, etc (which doesn't recommend any precautions with respect to public key exchange).  If someone was smart enough to find a mathematical hole in DHSS based on public key exchange, then they're smart enough to realize that there are much more profitable targets to be exploited around the globe than a $3,000 casascius gold bar...

Ditto.  Development has been remarkably fast and efficient since I "finished" the C++ blockchain code and have been able to work in python 100%.   It is delightful

Oh, I forgot I also added light networking to Armory using twisted -- connection to localhost bitcoin/bitcoind only, but can broadcast tx and retrieve tx not in the blockchain

Big Updates!

(1)  I just found a huge oversight in the way I was scanning the blockchain for wallet-relevant transactions.  I just optimized the hell out of it and got a full wallet-scan down to 0.75 seconds once the blockchain is loaded!  Sure, my computer is decent:  i5-2500K with 8GB RAM, but this is down from 5-15s it was before.  So, I can now get all the transactions for a set of wallets from a cold start in less than 20 seconds -- that includes reading blk0001.dat, indexing all the data, organizing the blockchain, and finding all transactions for my wallet.  That is FAST.

(2)  I have finished all sorts of crazy new features, but have forked my own project to Armory and been continuing development there, where I should be finishing a new client before the end of the year (alpha version).  I forked the project because I needed to merge the python code and the C++/SWIG code into a single, hybrid library, but I didn't want to disrupe the pure-pythonness of the original pybtcengine module.  So, if you are looking for pure-python, keep using PyBtcEngine, but otherwise you should start following Armory instead.

Teaser:  Armory will include multiple encrypted wallets, watching-only wallets, easy address-import, and will support multi-signature transactions (experimental)!   And that's not even all of it, but I have to keep some things a surprise

I'll be posting more in a new thread about this soon!  GUI development is slow, though...

Wow, nice work bwagner!  It sounds like the flaw has to do with the fact that point addition is easily invertible, allowing someone to "invert" your public key before using it.   They would have to have your private key (or solve a discrete log problem) in order to do the same thing in DHSS.

I suppose I could've gotten out pencil and paper and done exactly what you did, instead of ranting about it.  Your proof looks valid, using a typical proving method:  if this was insecure, so would ECDSA, so it must be at least as secure as other ECDSA operations.

But I still don't know why you wouldn't use the DHSS method, since it is established, and you don't need convince someone "I'm pretty sure this proof is correct."  Anyone can look up DHSS and see that it is an accepted method for doing what you are trying to do.  It's no harder to apply than point addition and even has a little bit of extra anonymity.

-Eto

My bad.  I thought you asked about looking up transactions for a given address.  It sounds like you have a tx hash and you want to retrieve the tx.  Yes, that should be an easy modification to bitcoind.

That's embarassing, I rushed through the thread and totally misunderstood the proposed solution.   My apologies.

You're right it doesn't require keeping public keys secret, but it doesn't change my objection to it.   As Mike Hearn suggested, it's a mistake to not use "established" techniques for any cryptographic protocol.  Is point addition an established technique for a secure system (I'm not familiar with it, but maybe it is)?   Just because an insecurity isn't obvious doesn't mean it's not there.  There's all sorts of creative math that has been used to break crypto schemes, and the only way to "be sure" is to use established techniques.

And the fact is there is already an established scheme:  which is using point multiplication as described multiple times before.  Diffie-Hellman shared-secret techniques have been established as secure, and if you have ECC-math module on your system, you can use it just as easily.  There's no reason to risk using point-addition when there's a widely-accepted alternative that gets you the same thing.  (In fact, the point multiplication adds a little bit of extra anonymity, since the tx with point addition can be identified with anyone having both public keys.  The multiplication tx can only be identified by someone with one of the private keys.)


The examples you speak of are protocols where your keys are expected to be revealed at the end of the exchange.  But, up to this point in Bitcoin, people reuse private keys all the time with the assumption they remain private.  Removing that assumption changes the security model for application developers and users.  As an app developer, I don't want to have to deal with simultaneously maintaining a set of private keys are okay to reuse, and a set of keys that are a guaranteed fail if I re-use them.  Sure, it can be done, but it's extra complexity in security-sensitive software.

Finally had some time to look at this, and I'm not impressed with the talk of point-addition:   as ByteCoin suggested, there is not a "robust" way to use point addition to secure anything.  Point addition on a given curve (where everyone knows the parameters, like secp256k1) is easily invertible.  Point subtraction is only slightly slower than point addition.  

Additionally, it is very unwise to rely on any method that requires keeping public keys secret.  This goes against the grain of cryptography, and creates a headache for those of us client developers that justifiably leave public keys unencrypted in wallets.  You can argue that some special CONOPS (concept of operations) designed for this application will help, but it's just not good cryptography.  Don't do it.

Going back to casascius' original idea:  you CAN use Diffie-Hellman shared-secret techniques to SECURELY create a shared key.  If Alice has (a, a*G) and Bob has (b, b*G), then by publicly broadcasting their public keys, Alice and Bob can both compute the elliptic curve point (a*b*G) and no one else can.   This gives us two options (in general):

(1)  (A and B)  Alice and Bob create the point (a*b*G) from each others' public keys, and use the result as a new public key.  They calculate the address hash and put it in the TxOut field of a transaction.  Then when the money needs to be spent, Alice or Bob can send the other one their private key, and then the combined private key can be computed and used to sign the inputs.  This is perfect for casascius application, but not many other applications (see below).  

(2)  (A or B)  Alice and Bob create the public key as above, and then use the x component (or combination of x and y components) to derive a new private key.  This private key can be converted to public-key/address that can be included on a transaction, and then Alice or Bob can sign for that transaction.  This isn't relevant for casascius' application, but it is cryptographically secure, and has plenty of other useful applications.

The problem with (1), in general, is that it's a terrible idea to create a crypto process that relies on exchange of private keys.  While a wallet/app will attempt to use a different private key for every transaction, there's a possibility that things go wrong -- someone else sends that private key money, a bug in their client (or someone manipulates their client)  to reuse private keys, multiple clients using the same wallet don't realize the key has been used, etc.  And a problem like this would go unnoticed by the user until someone has already exploited it.  This is in the same vein as requiring public keys to be kept private -- private keys should never have to be made public.  

Except for casascius' application:  his CONOPS already involves exchanging private keys and his software is specialized to do this correctly.  For general multi-signature protocols over the internet with untrusted parties (1) should never be used.  (2) could be used cryptographically-responsibly to replace 1-of-2 multi-sig transaction types, but that's for some other application.

P.S. -- I am very interested in ways that an (A and B) transaction could be created using "responsible" cryptography, but so far no one has suggested a way.  Such as a way for Alice to only compute the combined private key with her own private key and Bob's signature (or vice versa)...

Your bitcoind would have to do a full rescan of the blockchain, which it is probably prohibitively slow in the Satoshi client.  I'm sure the client could be hacked to do this, though.

Joint,

I did send you a BTC.  I didn't feel that it was worth 2 BTC, though, as it's a very generic font mainly and reusing the Bitcoin logo itself.  I know you put effort into it, but I cannot consider that as a logo for a serious organization.

Please PM me if you would like to discuss further.
-Eto

Hey folks, I'm realizing that i have no idea what I want.  I'm putting this thread on hold while I reconsider some of my branding ideas -- not just design, but perhaps the name, too.  I'll restart this thread when I have better direction. 

Thanks for the attempts!
-Eto

Hi bitcoinbitcoin113,

I like the idea, but there's something about your specific design that isn't sitting right with me.  Perhaps the lock is too big and text too small...?    Or maybe it's the gold Bitcoin on top of the padlock.  Perhaps if it looked like a regular padlock, but with a distinguishable (non-gold) BTC keyhole, that would sit better with me.  Though it might be tough to get such a thing to look right...

I think this kind of logo (with the name as part of the graphic) nice to have, but I'd prefer to also have a logo that has the "BitcoinArmory" outside, next to the graphic (like btc_artist has).  If I had both, that would be good/versatile, but I think I definitely need the version with big text next to the graphic.

Thanks for the attempt:  2 BTC sent!

It wouldn't be much of a "multi-signature required" transaction if one party can pull out the money alone.

I'm assuming the OP_CHECKMULTISIG works (with the extra stack-pop), and if so, everything else will fall into place -- if the tx is accepted by the network, it will be tough to get it wrong (unless you plug in a 1 instead of a 2 for a 2-of-3 tx...).  I got some GUI development to do, and testing my multi-sig construction methods on the testnet... but otherwise, I'm not far off.  I got all the other pieces in place. 

2 BTC sent!    

One idea my girlfriend just came up with was a shield with a "BA" in it in appropriate 12th century font:


(except inside a shield instead of a square)  I kind of like the idea, and it fits the name pretty well too.  I noticed that such a think might fit well on the top of your building instead of a circle.  Or perhaps the shield could be the logo itself.  It could even be planted in a pile of money/BTC...?  Just rambling at this point...

I should've known to go looking for free icons.  Those links are perfect.  I still wouldn't mind a few specialized ones (and pay for them, too), but it does seem that most of what I need should be there...

Thanks!  And keep the ideas rolling.  

By all means, I just don't know yet what icons I will need until I start laying out the UI.  However, I'll probably need stuff like send-button, money-recieved icon, money-sent icon, locks for encrypted/locked wallets.   "please wait" icon.   (I really don't like the 0.5.0 icons).

Is 64x64 a good icon size?  Could there be a problem with scaling down to a smaller size?  Perhaps, try scaling your 64x64 down to 24x24 and see if it still looks good.  If not, maybe make provide a good-looking smaller one along with it?  I'll throw in an extra 0.2 BTC for that

Hi btc_artist,

I really like the gist of the design, and you definitely deserve a few BTC for it.  I assume I should use the address in your signature?

Two things:
(1) While I know an "armory" would typically be "bigger", I really like the idea of having the building with less aspect-ratio, so that it will also fit nicely as a desktop/window icon.  Of course, that would probably break the symmetry of it, but I think the ability to iconify the non-text part of the logo is a huge benefit for my "brand."
(2)  It's really minor, but do you have any other ideas for font?   I actually like this one, but I'd also like a few others choices. 

I will wait for a few other submissions before picking one (and thus sending anyone the bounty), since I still have some time before I finish my first release. 
Thanks!
-Eto

I guess I don't fully understand yet (who's creating the big numbers? who is multiplying them?)... but I concede to the next paragraph and can save the details for an IRC discussion (or you can point me to some logs where you've already had this discussion--I'm very interested).

This is a good point, as I never realized before that there was more to M-of-N transactions than the obvious uses.  Unfortunately, the possibilities are limited to the ECDSA math tricks, not a generic scripting language like OP_EVAL...

Okay, take 2:  I responded before I had thought this through:  

You are saying "product of private keys" which I interpretted to mean what is used in Diffie-Hellman shared-secret process:  I have private key a and public key a*G.  You have private key b and public key b*G.  If we have each other's public keys, we can both produce:   a*b*G, which is a point on the secp256k1 curve that only you and I can calculate.  That point could be used to create a new private key, and that is converted to an address to be included in a TxOut script.  Then a signature for that address can be produced by me or you.

That is the only way to "multiply" private keys without actually handing the other person your private key, which I don't think is ever a good idea.  I'll think a little more about how it would be possible to get an A-and-B address transparently into 20-bytes.

Ack, please don't tell me we're allowing recursion in OP_EVAL?  Or at least, unbounded recursion...?  I'm envisioning someone finding a bug in OP_EVAL which causes every node on the network to hit the recursion limit on their system and crash the moment the tx hits the network...


Your C address would be a "diffie-hellman shared-secret" private key, which can be produced by either A or B (using their own private key and the others' public key).   I presume you mean, calculate the public key for that private key and make that address C?    Then technically, a transaction that ONLY includes C can be spent by A or B, IF they have each others' public key and know about it.  

Therefore, making a C-or-D transaction using the C just described and third party D, would be one way to make an (A-and-B)-or-D transaction that fits into OP_CHECKMULTISIG protocol.  It will just require A and B to exchange/notify each other of public keys, and an extra step to produce the shared private key before signing the tx.

EDIT:  Ack, I botched the conclusion here... C-or-D would be the same as A-or-B-or-D.... clearly not what we wanted...

Just for clarification to make sure there's no confusion:   the upcoming changes for supporting multi-sig transaction as "standard" in the network will have one-and-only-one form--the form that uses public keys only, and OP_CHECKMULTISIG.  As such, an 2-of-3 transaction might look like the following:

TxOuts will look like:

And the associated TxIn scripts will look like:

Then, when the scripting engine reaches the OP_CHECKMULTISIG symbol, the stack will look like (for the 2-of-3 tx):

Also, these are the only multi-sig transactions that will become standard? What about (A-and-B)-or-C tx types?  And the only options for (M,N) are {(1,2), (2,2), (1,3), (2,3), (3,3)}?   Are 1-of-1 transactions (as silly as they would be) considered "standard"?