Gavin will soon be starting work on Bitcoin full time, but I think most of his effort will be going on stability, scalability, code maintenance and other such things. I'll get around to working on contracts stuff eventually I hope, but the work needed for mobile (in person) payments is taking priority.

It's certainly true that the project could use better organization and more of an authoritative voice. First step would be an improved website with a "project ideas" type section.

LOL. let me know when I can exchange my forkcoins for BTC :-)

You can't have for loops in script, so hashing 10000 times would require that you have 10000 opcodes.

There is a limit on the number of opcodes per script, so it wouldn't be extendable.

There is a more important issue than no loops, namely that output value can't be set by scripts.

To get an idea of how powerful this is, with this kind of scheme you could include a payment on every packet going over the internet, or all kinds of extreme micro-payments.

We only need need to eliminate the uncertainty of of the product/service bargained for. Then there is no need for trust at all.

I'm thinking of a fractional reserve insurance association. Because bitcoin is so certain you only need to insure the risk of loss/damage of the non-bitcoin half of the bargain.

Many of the centralization and trust issues in the Bitcoin economy have technical solutions, but unfortunately the required skill and time to implement them is scarce. Collecting proposals on a forum thread won't change that - what's needed is people to step up and implement them.

Issuance of USDcoin/EURcoin etc is one way to reduce needed trust in exchanges, but they still need to back those coins and interface with the banking system. It's possible to decentralize exchanges further using ideas from Ripple.

I think the focus on Open Transactions is misguided. FellowTravellers passion is admirable but as far as I know everyone who has looked at OT walked away overwhelmed by its complexity and generality. Simpler, more specific systems are likely the way to go.

Many of the centralization and trust issues in the Bitcoin economy have technical solutions, but unfortunately the required skill and time to implement them is scarce. Collecting proposals on a forum thread won't change that

agreed, but the ability to store ones wallet in the cloud is essential for mass adoption.  The faster someone figures out how to do this properly with immediate confirmation, the faster you will be able to use BTC retail.

I agree this is really dumb from a liability perspective and you are asking for trouble IMO.  If you are at The Institute and don't want to spend money on a lawyer, I would strongly suggest you consider talking to Ron Rivest.  He is not a lawyer, but I think he will be able to give you very very helpful advice.  First he is very familiar with anonymous e-cash, as he's studied and published on it.  He's also started two crypto-based micropayment companies (peppercoin and another) so he is likely quite familiar with the relevant laws.  Third, and most importantly, he has first-hand experience in dealing with situations where ugrads get themselves into a world of shit (see charliecard incident).

Now, to be a huge asshole and maybe motivate you more, I'll say frankly I'm not impressed with this.  I bet I could take a uniform random ugrad in CSAIL, hand them a basic description of blind sigs, and they would produce what you did.  Here is what would impress me: do this without any liability by not requiring trust even for you to not run with the money (i.e., let people do this entirely p2p without trusting anyone).  Seriously, think about it before you read the next paragraph, and if you realize how to do it great.  If not I probably wouldn't either when I was a ugrad, so here's how to do it.  Unlike blind sigs, even with this description there is quite alot of work to go from idea to reality.

---

What you are basically providing is a protocol where N people can submit bitcoins to an address under your control, and then you will spend them back to N different addresses without knowing the mapping.  First observe people don't need you at all for this, because bitcoin supports multi-in, multi-out TX.  So N people can do this without you.

Attempt 1:  N people who want to mix coins get together and build a TX.  We get together in a circle and, starting from a blank piece of paper, pass it around the circle, each step adding our input and our output to a random location.  After it has been passed around once, it gets passed around again.  This time, assuming my input and output is still there, I sign the tx and pass it on.  If everyone signs it, it is broadcast and we're done.

Problem: This is entirely secure from outsiders, but leaks information to other participants.  E.g. if you are first in the circle and I'm second, I know your input/output mapping.  Similarly if you're last and I'm second-to-last.

Corrrect solution:  Realize what you have is basically a protocol for N+1 participants, where one is a trusted third party to do the input/output mapping.  There exists a generic transformation, called Secure Multi-party Computation that takes such a protocol and eliminates the trusted particpant to yield a cryptographically sound protocol performable by the N parties.  More precisely, for any function f, N people can compute f(x1,...,xN) without revealing their xi.  At the end each party only learns about others' input by what is revealed from f() itself.

So here the setting is xi = (input_i, output_i, secretkey_i, random_i) where input/output are desired addresses, secretkey is the ECDSA key for the input, and random_i is enough random bits to specify a random permutation perm_i on [N].  The output is the following TX, signed by all parties.  Let perm = perm1 o perm2 o perm3 o ... o permN.  Note that if even a single person chooses his permutation at random, then perm is a uniformly random permutation.

inputs: input1, input2, .. inputN.
outputs: output_perm(1), ..., output_perm(N)

Note at the end, all I learn is the inputs, outputs, and that in the overall perm my input was matched to my output.  In particular, the input:output mapping is a random permutation conditioned on knowing the value at one point.

Now that would impress me, and many others too.  In particular existing MPC protocols are likely not practical.  You will likely need to do some work studying the work on 2PC that has been done since the 80s to make it practical.  AFAIK not much has been done since the original defn in [Yao 82] to make general MPC practical.

It's also possible that there's a way to make the paper-passing protocol secure with many more rounds that involve adding garbage addresses and removing other peoples, only to have them add a new one back later.  It seems tricky to get privacy and get something like this to eventually converge, but I can't rule it out entirely so wouldn't dismiss it yet.

That's the most common argument leveraged against LastPass, and it's indeed valid (see below). The solution, so far not implemented anywhere, is to sign a hash of the JS snippet in question and have that verified by the client. When the code needs an update it has to be vetted before clients approve a new hash or signature.

I believe this is on its way into the HTML specifications but I haven't looked for some time. If we control the client implementation (Android, PCs) it's however implementable already today.



In the LastPass case, they are considered trusted (reputation, company) and the architecture is meant to protect against hacking instead. They take great care to make sure their systems serving up the JS in question aren't easily manipulated, and if a hacker were to extract their databases they still cannot do anything with them since everything is encrypted and only the end users have the corresponding keys.