Disclaimer: it's late at night and I'm not an expert on cryptography so most of this is probably ignorantly wrong.

I've recently come across something called "functional encryption" and thought it might have useful applications for solving trust problems in complex transactions (almost any situation requiring a third-party to provide a service.)


(This paper then goes on to improve garbled-circuits by making them reusable, anyway those are the relevant definitions of functional encryption.)

So my understanding of this is that you can take any function F, convert it to a functional encryption scheme complete with public key cryptography, and use it to compute arbitrary outputs on a given set of input(s) WITHOUT revealing any of the internal workings of F (not to mention your inputs)? So for example, you could define a function that adds 10 to an input and all of the logic for the program (including it's execution would be encrypted.) Now suppose for a moment I've understood this correctly (and I probably haven't lel), but couldn't this all be used by third-party mediation services to provide verifiable proof of the signing services they provide for Bitcoin transactions? Essentially, you would create an arbitrary function that has transaction validation logic inside including an ECDSA private key for signing transactions, turn it into a functional encryption scheme - and bam - you now have a deterministic, third-party service WITHOUT trust. You could then throw away the private key completely and give away the functional encryption scheme and it would be limited to providing the service it defines. Now if you were to make a new deposit into an address protected with that ECDSA priv key, you would know -before hand- exactly what services the address provided, indeed, what it -could- reasonably provide (which would help eliminate any blackmail attacks on your money as well as safe-guarding against the service's disappearance. )

Other then that, I can't comment about the practicality. I have heard it's slow. How slow does it need to be to be broken though? Even if it took a whole week for output from one of these functions to be returned, the result would still be a decentralized, self-contained service, without the shoddiness of third-party trust but vastly improved security. What other limitations are there? Aside from the speed, is the program itself executed in a way where it can be reversed engineered? I mean, if we have homomorphic encryption, maybe "functional encryption" is exactly what it sounds and we can start making more secure services.

Anyway, time to sleep. Let me know if these ideas are going any where  

Plz read whole thread.

I'm coding my own peer to peer network and I've noticed there aren't any good libraries for the most simple tasks. What I mean by simple tasks is getting two peers to find each other and to reliably connect. This isn't as simple as it sounds because most peers are behind a router that does NAT and this means you need to do port forwarding to accept inbound connections, which frankly isn't a solution for the average user.

So what I'm doing at the moment is writing cross-platform Python code which uses a number of techniques to connect two peers. I've already written a simple class to forward arbitrary ports with UPnP - all automated with no outside dependencies. My class is a single module that works like this: UPnP().forward_port("TCP", 15666, "192.168.0.5") - (specify destination port as the forth param if its different from source) - it couldn't be easier.  I'm also including code for NAT-PMP which can be used for port forwarding by some routers that don't support UPnP. Finally, I'd like to be able to create a simple implementation of TCP hole punching for developers that works cross-platform and is properly documented. This technique has been well documented in academic papers and RFCs, but has yet to be widely used in software.

The reason I started this thread is because I need boxes to test my code. NAT traversal code by definition requires more than one peer behind a NAT and I only have access to my home connection. Even with multiple servers I cannot easily simulate the diverse NAT environments that will be in use in the wild (or ensure it even works when it comes to the real thing.) So I'm asking if anyone can contribute a spare box behind a NAT so I can work on the code. I only need access to a shell behind a NAT (any NAT / router - the more, the merrier) and I can do the work. If trust is an issue, feel free to cut off anything I don't need and heavily monitor the box.

Why should I help?

If I'm successful, this work may have implications for improving the connectivity in Bitcoin as well as in peer to peer networks in general. Not to mention developers will get a simple library for writing peer to peer programs, with the potential of ports to other languages and (possibly) the eventual inclusion in Bitcoin Core (assuming core devs think it's a good idea.)

Exceeding too long; I have declined to read further

Writing open source library in Python for simplifying peer to peer connectivity, and I need boxes for testing. If anyone wants to help then please keep this thread bumped and/or message me with node details.

We should build a blockchain for governance. (Don't ask me how it would work because I haven't thought this through.)

The answer to Bitcoin's security problem is very simple: do not place all your trust in one place. A very simple example: suppose a traditional wallet on your average person's computer. One set of keys in one place. Very easy to steal. Vulnerable to drive-by exploits, trojans, social engineering attacks - etc. But we can add as many keys and factors as we need to protect a wallet. If the standard Bitcoin client included SMS security codes, it would make stealing coins extremely difficult. Now you need control over the victim's phone to move money and they can issue the final approval by inputting a code. Ultra-paranoid mode would use additional isolated devices.

Though I agree that realistically, anyone can be hacked given enough time and effort... but there does come a point where the probability vs reward isn't worth it for the attacker. Creating these conditions is trivial.



A better idea would be to use multiple redundant keys. Once again, there is no reason to put all your eggs in one basket. With the above security proposal - backup keys could be written to a USB drive or encrypted and saved to a remote server at wallet creation for use in the event that access to the phone was lost. Most of these security proposals are already in wide use.

I'm sure this is already pointed out in the thread: but Bitcoin is more than the code that runs it. Bitcoin is an idea with a set of universally accepted properties: 21 million units of currency, decentralized, bla bla bla.

If this dooms day scenario of yours were to be played out then the resulting work wouldn't be Bitcoin and everyone would switch to a version of the code that was. That is the advantage of open source: we all have access to the internals of Bitcoin and version control tracks all changes. We're not using the Bitcoin code because we -have- to -- we're using it because we want to, and what you suggested is something no one would want. So in essence, the perceived "control" that the core developers have over Bitcoin is based on being able to do what the majority of people consistently want. Thus, there isn't a way to control Bitcoin without also controlling the majority of its participants. Satoshi thought of that too.

In conclusion, so long as people think Bitcoin should be like... well Bitcoin - then it shall be. (The idea itself is decentralized )

Try to understand how Bitcoin solves the byzantine general's problem because it is crucial to understanding how Bitcoin works.

In this old thread on the cryptography mailing lists, Satoshi himself describes how nodes in the Bitcoin network come to consensuses: http://www.mail-archive.com/cryptography@metzdowd.com/msg09997.html

What comes to mind is the repo on source forge: http://sourceforge.net/p/bitcoin/code/HEAD/tree/branches/multiplatform/

There are commits from what appears to be Satoshi going back to 2009.

Coming soon.