Yes, and yes. However it is just the two of us, and unless we meet our donation goal our time is split among many, many different projects, so progress has been slow.

There's no way you'd want transaction validation to depend on responses from a specific server. That would destroy distributed consensus. I think that's a terrible example of what to do on the block chain, but if you were to do it you'd have to depend on data committed to the block chain in some way. Otherwise you are destroying the security guarantees of everybody else who uses it.

It has secp256k1 in git master, although not in the last release I tried. If you don't want to track head, it's simple enough to monkey-patch in support:

Replacing the scripting system with SNARK proofs has non-serious problems that remain unsolved. Verifying keys for SNARKs are huge, so it is completely impracticable to compute arbitrary new proof circuits for each output. The most likely alternative is that you compute shared proving and verifying keys for a Turing-complete virtual machine, like tinyram. The problem now is the nature of how the key is generated: a security parameter is chosen which is a sort of master skeleton key - if kept, it could be used to spend anyone's output undetectably. That's no laughing matter. Every known SNARK system with practical requirements has this limitation. In theory you could do some sort of large multi-party compute to create the key in a way where only one participant needs to be honest to ensure destruction of the trapdoor. However besides the practical difficulties of doing this (orders of magnitude greater size problem than anything that's been handled so far), there's the the fact that it only shifts the problem. Practical MPC systems work on the same principle - whoever created the MPC parameters could backdoor that calculation and derive the SNARK security parameter. Try to solve that and its turtles all the way down...

If that weren't bad enough, there's also the issue that while validating a SNARK proof is cheap, creating it is *very* expensive. These sorts of things are typically done on small HPC clusters. It's pretty ludicrous to think of doing it on a smartphone.

Now making a more expressive scripting language is very much possible, but requires being very careful. I'm working on some proposed bitcoin extensions for this.. if anyone is interested in helping out, feel free to PM me.

why?

If you want to make a hard-fork change to bitcoin, then you need every single node to upgrade. You need 100%.

It happened a couple of times in the early history of bitcoin. At this stage, it's basically impossible except in emergency response to consensus errors.

There's no reason you can't do CoinSwaps across chains (it's even mentioned in the introductory post). Maybe you're thinking of CoinJoin?

This is incorrect. See, for example, CoinSwap and the atomic exchange contract on the bitcoin wiki as ways this could be done now.

Also, with protocol extensions the limitations of these techniques could be worked around as well.

Yes, yes you could.

Andrew, I don't think that is an issue for wallets that natively support mixing. Let's say you measure effective mixing by the logorithm (bits) of the estimated anonymity set size, and within your wallet outputs are tagged with this value. If you use an input with anonymity set size N on a mix that is estimated to add M bits, then the mixed output has N + M bits of anonymity, and the change output keeps the original N bits. Does this make sense? There are some assumptions about independence and randomness in selection of join partners here, but those are assumptions that can be kept through proper engineering.

No, if it happens it's taxable. If you fail to declare it, you are evading taxes and just haven't been caught (yet).

Can you explain this one? I don't think it follows. A given transaction should have common sizes, yes (see: CoinJoin), but I don't think it follows that all transactions need to have that same transaction size. Each join can use a facilitator-chosen size so long as the wallet is capable of tracking the anonymity-set implications for each of its outputs.

No, don't give testnet coins any value or purpose. In doing so you destroy their purpose.

Create your own assets for this, if you wish.

If you buy gold for cash in person, guess what? It is taxable.

They sign a list of their outputs, some of which are explicit, some of which are blinded. The blind signed outputs are separately checked (the server blind signed them without knowing what they were, so couldn't later skim them without detection). So each participant has a list of non-mixed outputs signed by their owners, and a list of blinded outputs signed by the server before it had a chance to do any funny business. Together these should add up to the entire transaction (modulo facilitator and miner fees).

No, the server can include this signed information in the message it sends to participants.

The solution is simple: each participants sign what outputs they want to see on the chain. No participant signs the transaction unless they receive invoices separately signed by every single input which cumulatively add up to the transaction. Cryptographic blinding is used to make sure that users can specify hidden outputs not subject to this check.


Google "bitcoin stealth address"

Reference the original offers in the join request, so that anyone considering signing the transaction can make sure that not just the correct outputs, but also the correct number of outputs are present. My Python implementation does this.

You would never sign it.

Oy, there is something wrong as I have not been receiving email updates about this thread. My apologies to everyone.

So an update on the current status:

A BIP describing the authenticated prefix tree resulting from my research has been published to the developer mailing list, and is available for view online. The feedback I got from that is being worked into a 2nd version of the proposal which is nearing completion (I'm currently adding descriptions of the peer-to-peer messages and JSON-RPC APIs, then it is finished).

I also have about 80% written of a BIP describing the validation index, the outline of one describing the wallet index, and an assortment of notes towards two future BIPs related to document timestamping and merged mining improvements. These are the first deliverables, as once developer consensus is achieved other people can start working on implementations of these various features.

Besides the python implementation hosted on Github, there's a C++ implementation suitable for inclusion in the reference client that is about half finished. It could use a lot more unit tests.

However since funding mostly dried up after Armory's very generous donation some months back, I have been working on this proposal only part time (1-2 days per week). The rest of my time is spent on various other funded projects including CoinJoin and preparation for blockchain pruning. Work has not stopped, just slowed down.

@dansmith, unfortunately I think there's some confusion. I did not switch addresses between the first and the second funding rounds, so most of the money received at that address was for the first round. (And, while it sounds like a lot, bitcoin was worth an order of magnitude less back then and it was mostly cashed out upon receipt. Too bad I don't have a knack for predicting markets :\ ) I was unable to finish out the round, so I've been forced to take on other (thankfully related) work as well which has unfortunately slowed things down.