Gavin, I looked at the papers Bytecoin cited, to see if it is worth effort implementing this.

Especially the first paper is very intersting. I agree that it should be possible to adapt the two zero knowledge proof parts from the Paillier crypto system (for which the paper gives a solution) to elliptic. Moreover, it probably involves quite a bit of thinking and implementing; it's not really as straight forward as it may seem.

Therefore, I spent a few hours analyzing the situation. I think that splitting private keys in the form you describe in your first post is the right direction but not really what we want. Let me first outline some problems I see with your approach and then provide an amendment to your thoughts.

Risk of loss: Suppose, we lose one of the two devices. Then we have lost our money, since we no longer can form the requested signature. Thus, while we gain more security against attackers, the burden on backup gets higher: We now have to backup two devices and we should do this after every generation of new keys. Lose your laptop, drop you mobile on the floor: Your money is gone. Two devices - double risk.

Burden of key-splitting: Every time we generate a new key, the two devices must synchronize, for the scheme to work. So: When generating a new bitcoin address, I need a new PAIR of private keys, which requires an activity on both devices. If you only have one device with you on generation time, you have got bad luck.

Usability: Looks like I always have to have both devices on me when using Bitcoin. Sometimes I will not. So I might end up having some small cash on some addresses which are only on one device. Or the other. And only the addresses with the big money are secured by secret splitting. Which may lead to user confusion and a hassle when trying to get the devices synchronized.

Mobility: Right now, BTC is a desktop application. It will become a mobile application. Fine. So will i need two mobile devices in that scheme, when I am having my beer in bitcoin bar? One could be a mobile phone. And the second? Smartcard? USB token? Second phone? How useful are two devices for a mobile solution?


Currently, I see two ways out of most problems: A cryptographical one (using a different crypto scheme) and an operational one.

Cryptographical idea: We do not want private key splitting, we want more. We want a threshold scheme with proactive sharing (and, if possible, verifiability). This means:

Threshold: We split keys not into two but into a larger number. For example: Five. (Desktop PC at work, desktop PC at home, mobile phone, smart card, USB token). We impose a threshold. For example: Two devices together can produce a valid signature. This solves the backup issue. Lose one device, you still have four left. I think, this threshold concept if a major improvement of the backup situation.

We have to modify the life-cycle of the keys, of course, to solve the other issues mentioned above. No small pools any longer, but 1.000 keys or more which are generated at the beginning. So we do not have to distribute fresh key shares so often.

Proactive sharing comes into the game, when we lose one of the devices. In this case, we want to disable the keys as fast as possible (before the attacker manages to steal a second of our devices). Proactive secret sharing allows us to redistribute the shares in such a manner, that compromised shares lose their value for the attacker.

Verifiability comes into the game, when one of devices is not lost but compromised or defective. It allows the other sharing participants to check if a sharing participant lies about his share (but, of course, without learning anything about the share).

For elliptic crypto and DSA, there exist threshold based signature schemes. I am currently researching, if there are proactive schemes (I assume, yes) or verifiable schemes (I do not know).

This concept should work without touching anything on Bitcoin crypto - we only add a wallet client.

Organizational idea: We do not split at the wallet private key level, but at the level of the user.

Our wallet is handled by a secure and trustworthy organization or node. We tell that organization or node using secret splitting schemes as outlined above, when they are supposed to use the wallet keys on our behalf. The node might be a pluggable PC such as openplug.org running out of my home (with a backup of the keys stored somewhere). The activating devices then are a smartcard to be put into any card reader and a mobile phone. These two devices would not have to use Bitcoin elliptic crypto but just ANY existing key sharing scheme (which is much easier to do). Again, Bitcoin client does not have to be modified.

The advantage here is: When I lose one of the devices, I do not lose my bitcoins. Not only the attacker has no advantage, I have no damage in case of a loss. It is easy to get a new mobile and place it in synch with the second device and the trusted node.

Those who do not want to buy a pluggable PC can delegate this to an authority they trust. (I admit, this is not completely satisfactory. So, rather, have your own pluggable PC).



Would be great to get a bit of feedback on these thoughts.

Thanx.

Very interesting paper.

And the method is patented or patent pending  http://www.freepatentsonline.com/20030059041.pdf

I appreciate your posting as well.

The core reason for my fascination in BitCoin is the empowerment of the individual to make its own choices and decisions, independent from a force controlling the intermediaries.

Let this apply to money, that's fine. Or to other parts of society, be it domain names, content, whatever.

It was heartwarming that there are others here with similar inclination. 

@Maged: Great help. Works. Thank you.

Interesting approach, indeed. 

Which option do you prefer?

Option 1: Look into my eyes and repeat after me: "I shall always trust the Bitcoin protocol". Now walk away, go and play, relax and take it easy.

Option 2: Check your options, educate yourself and make your informed choice on which form of Bitcoin you want to use.

Interesting video. I also checked out node-bitcoin-p2p and I like the idea of the node.js based server very much. Smart! Any additional source on the additional protection you offer regarding security? I'd like to understand the advantages a bit better.


The reason is second source and freedom of choice.

We do not know today, if there is some problem with the bitcoin implementation, with the chosen parameters, with the economic model, such as bounty reduction, fee structure, verification mechanism. We do know that Satoshi is/was/were (an) extremly smart guy(s) and had thought of numerous issues (just read his client code - absolutely brilliant!). We do know also that having to rely on one monolithic system is bad. Bitcoin is the first step (from a centralized moentary system to a decentralized monetary system). Still, Bitcoin is monolithic. One protocol. One set of parameters. One set of economic rules. Thus from this point of view, the next step is obvious. But, if taken to early, it could also kill the current system.

How? Remember: It is a P2P architecture.

Bitcoin 2.0 ? WTF ?? We haven't got Bitcoin 1.0 running and accepted - so what is this rubbish. 

Well, have an open mind and read on. 

While I am writing up some pages on Bitcoin economy, I came across the following observation: If a major bug in the Bitcoin program shows up, eg. some fancy buffer overflow which allows remote coin theft, the course of Bitcoin is likely to crash.   

Of course, with Bitcoin this is not possible.  It has been coded very well. But still...it has been heared of many times, that even programs like Windows (watch out: irony) have bugs. Read on !

So, assume we had multiple implementations fo Bitcoin. Bitcoin 2.0 and Bitcoin 3.0. Of course, these would be built on different clients, maybe slightly different parameters regarding bounties, fees, hash algorithms and stuff. They would be convertible into each other on the click of a mouse (or even by automated action). In such an ecosystem there is the chance to switch currencies. If Bitcoin 1.0 runds into trouble,
no problem, you just switch to Bitcoin 2.0. And, of course, you would not have all your assets in just one of the Bitcoin variants, but you would distribute your money accordingly.

Now my idea ist the following: A multi-variant Bitcoin world is probably not a good idea right now, as Bitcoin 1.0 is struggling for acceptance, but in the medium and long run, having several Bitcoin variants would be of mutual benefit for all involved Bitcoin variants. I am not saying that Bitcoin 1.0 has problems...I am arguing that the mere possibility of switching from one variant to another variant increases trust in all variants.

Any ideas on this ?

 

How will you ensure, that the 2.00 BTC which the hostile terminal shows you are about to pay isn't 450.00 BTC. Ie: How do you plan to deal with the hostile display issue? Will your device have its own screen?

Agree, that one should not change crypto light-heartedly. 

I understood the original suggestion as an additional option and possibility to be offered, just for testing.

Moreover: In my contribution yesterday late at night I demonstrated how the two devices can do a joint signature with both of their keys. However, I did a short security review and found a flaw in the scheme. My suggestion requires a communication from device 2 to device 1 and then another communication from device 1 to device 2. The second communication must be trusted otherwise the private key of device two can be compromised. Since Gavins idea was to split trust between two devices, this does not work:

Device 2 sends $d_2^{-1}z$ to device 1. This is secure, since $z$ is random. Device 1 generates $k^{-1}(d_2^{-1} z+d_1 r)$
 and sends to device 2. Device 2 then multiplies by $d_2$ and publishes the result.

Therefore anyone who is able to snoop into the second inter-device communication is able to reconstruct $d_2$. So the obvious attack vector is to compromise device 1 and the job then is done.


Why? Personally, I prefer it to be discussed in the forum, where there is better access, where there is generally better visability of the topic and more contribution by others and more transparency of the process.

Ist es auch schon. Ich habe im englischen Bereich darauf aufmerksam gemacht und es gibt bereits einen inoffiziellen Bugfix für jene, die selber kompilieren. http://forum.bitcoin.org/index.php?topic=19168.0

Ich habe darum unter guiminer jede GPU immer an zwei Pools hängen, da ich 4 GPUs habe, sehe ich aus Optik der Pools eben etwas kleiner aus, habe aber keine Downtime, wenn ein Pool mal nicht funzt.

If you allow two communications between the devices, couldn't it be done as follows:

Device 2 calculates d^-1₂z and sends this to Device 1.

Device 1 then calculates k^-1(d^-1₂z + d₁r) and sends to Device 2.

Device 2 multiplies by d₂ and has the result.

In the german part of the forum we currently are discussing a very delicate, dangerous bug in the GUI.

If you enter 0,005 as amount to be sent, the client sends 5.00

For the US-only localized guys I must add: 0,005 is, for example, in Germany the natural way to type what in the US would be typed as 0.005 - and this is consistent with all kinds of localizations in the operating system.

So a German user is likely to send a much higher amount than she intended to. 

We have the bug confirmed on the 0.3.23-beta client on Windows 7 by Dennis1234 and on the 0.3.23-beta client on Linux self compilation by mself. Since my client is running in testnet currently I did some testing:

0,0005 is parsed as "error in amount"
0,005 is reparsed as 5.00
0,05 produces an "error in amount"
0,5 produces an "error in amount"

Reparsed as 5.00 means the following:

I enter 0,005 and upon "Send" the displayed amount changes into 5.00 and I get an error on insufficient funds (I do not have 5 BTC in my current testnet account). From the normal behaviour of the client I assume that, if I had more than 5.00 i would just lose these 5.00.

I am not into wxWidgets programming otherwise I would do it myself. I think it is VERY important that we get that fixed ASAP !

Ich kann das für den 0.3.23-Beta, Linux, Eigenkompilation ebenso bestätigen :-(

Gut, dass ich ein Testnetz habe :-)

main.h: CTransaction::IsFinal() decides, when a transaction is considered final.  

Now, it looks like nLockTime is not really used currently, so if is the line

if (nLockTime == 0) return true;

which usually is doing its job here.  

A bit lower in the code there is this little thingie:  

if ((int64)nLockTime < (nLockTime < 500000000 ? (int64)nBlockHeight : nBlockTime))  return true;

which I personally would have expected to be  

   if ((int64)nLockTime < nBlockTime)  return true;

What is the purpose of comparing to BlockHeight in case nLockTime is smaller than 500 000 000. 500 000 000 is definitely in the past?  

As nLockTime is compared to GetAdjustedTime() earlier in the code, it is absolute Unix epoch time. 500 000 000 is November 05, 1985, 01:53:20 in my timezone. What's the idea of comparing with this date in the past ?!? Moreover: if nLockTime < 500000000 then almost certainly also nLockTime < nBlockHeight so this earlier test does not make sense ?!?

I would appreciate any ideas shedding some light on this line of code.

And, while being in this part of the code, a bit lower in IsFinal() we find:

   BOOST_FOREACH(const CTxIn& txin, vin) if (!txin.IsFinal()) return false;

The logic is obvious: If an input to a transaction is not final, then the transaction under consideration is not final. But...hm...shouldn't this be the very first thing to check? There are various cases earlier in the function which lets the system decide that a transaction is final - without having made this check.

Me too. Lets try to help each other. Not sure if all my answers are correct, but I will try...


I think this depends on the pool server, handing out different shares to the miners. Maybe you get some info on this at the mining part of the forum or at some good pool.


To the extent I understand this: You only need an already prehashed part of the block to mine, but the entire block to claim the bounty. Pool server has the block; miner only has the prehashed part. This might be wrong; I am still trying to understand this myself.


The pool software gets the value of the nonce and then can complete the block, relaying it to all other nodes.


Payed? Actually by solving the block the block solver becomes already owner of the transaction which grants the money to him. It will take a while until other blocks are found and the chain becomes longer - and this can be trusted.

Any results yet?

I am asking since I am doing a similar experiment.

I am in the process of discovering testnet and this hint here, but I would be interested in a completely independent fresh start, ie. one, which starts with its own genesis block as well.

We might share experiences!?

That was just my motivation.

I hate being locked in by the decision of others. So unless I am able to figure out every bit on my harddisc, I feel uncomfortable. This does not mean I have to do this every day, but I want to be able to do it NOW when I want to do it NOW. 

Which means I need access to tools and not just source code I could, eventually, read, to build these tools, if I wanted.

I am thinking about a variant of this proposal and would like to probe into its technical feasibility and democratic acceptance.

The client gets amended by a functionality. The "owner" of a bitcoin address / wallet can decide herself not to accept money from a specific bitcoin address X. To prevent circumvention by laundering this would mean that the owner also would not accept money from another bitcoin address B, in case there is a "trail" into the past which ends up at address X. It is similar to the statement: "I do not want to be paid by AlCapone and I do not want to be paid by JohnDoe unless JohnDoe is able to demonstrate to me that he has funds available in addition to what he might have received by AlCapone" (and of course additional variants in case there is more than one intermediate). Since blockexplorer is able to trace BTC streams, this can be detected.

1) Alice decides not to take coins directly or indirectly from Mallory. So Mallory passes his money to Bob, who passes some of his money to Carol, who passes some of her money to Eve, who passes some of her money to Oscar. Now Alice is telling Oscar that she is not willing to accept his bitcoins as a settlement of his debt, since, according to her analysis of the block chain, all of the money Oscar owns could be seen as originally coming from Mallory. (BTC have no identity, so a more thorough analysis may be necessary for this). So unless Oscar also did business with John, who never received any money from Mallory, Oscar will not be able to pay Alice using Bitcoins.

Of course, at first sight, this is to the disadvantage of Alice. But it is just with egression filtering in network security: It does not help the network doing this, but it helps the entire community. After a while, everybody knows that Alice / MtGox / etc. will not accept money which can be traced back to Mallory - and so nobody is doing business with Mallory any longer.

The important word is scalability: So long as only Alice reacts this way it is to her disadvantage. Assume, Mallory kidnapped someone and requests money to be sent to his bitcoin address. The story makes headline news and, say, 1 in 8 bitcoin users decide to blacklist Mallory. And many others might follow, since they realize that money they received from Mallory (probably via intermediaries) is not accepted in the community. So, in case there is a broad consensus by many individuals to blacklist Mallory, it would should work out to blacklist Mallory. Since this form of blacklisting is a decision of the individual, no centralized arbiter or court is necessary; the solidarity of the community is sufficient.

2) How would this be implemented? Of course, Oscar can transmit a transaction from his account to Alice's acount and this would become part of the block chain. So Alice HAS the money, even though it does not show up on her wallet until she is back from her business trip and goes online with her wallt on her desktop. But if Alice maintained a publically known blacklist of bitcoin addresses (either as part of her ecommerce web site where she posts that she is accepting BTC (with the exception of these 3 blacklisted addresses) or a signed blacklist which is public and certified as part of the block chain in just the same way as transactions are presently), then Oscar would have known about this blacklist. And Oscar would not have accepted money from Eve...and back the chain up to Mallory.

We thus would have a democratic majority against accepting Mallory's coins.

The necessary adaptations would be
a) An analyzer for the BTC stream from Oscar back to Mallory
b) Optionally: An extension for managing signed blacklists