In the CA system any one of those 100 certificate authorities can break your security - 100 single points of failure. In Tor that's just 7 single points of failure, and IIRC Tor does have a n of m scheme for directory authorities.

As the experts have known for years, you can do even worse than centralization, significantly worse: you can have numerous points of failure distributed around the world where failure of any one breaks your security. The certificate authority system is exactly that.

genjix: Yup. Scaling works out nicely too because the additional CoinJoin traffic will never be more than a small multiple of the existing transaction traffic, so doing all the CoinJoin communication via global broadcast messages is actually reasonably and efficient enough; gives good privacy for that communication. You can also reuse bitcoin age as a limited resource for anti-dos.

It's not as pretty as more clever crypto, e.g. the zerocash project that I'm also now working with, but has the huge advantage that its flaws are easy to understand and predictable. We want diversity in the level of engineering in the solutions we come up for to solve problems; CoinJoin + zerocash are two totally different approaches, and if one day we can use both we're more likely to actually achieve privacy.

by-sa is perfect, thanks!

Really good work, thank you!

re: copying, maybe I missed it, but could you add an explicitly creative commons share-alike license?

Sharing ephemeral keys between senders isn't a good idea; the ephemeral key can be used to prove you sent the funds without showing what exact inputs were used. Secondly having separate pushes is both non-standsrd right now, and unlikely to ever be made into a miner committed index.

genjix: putting the op-return prior to the txout In the standard is a good idea, though may conflict with merge avoidance techniques; need to think about that some more prior to releasing v1.0

 I'm working on getting rid of the restrictive IsStandard() rules too, which would let us do things like put the ephemeral key in the txout directly too.

FWIW here's a proposal for replacing the IsStandard() script template whitelist with a much more generic opcode whitelist that preserves forward compatibility and doesn't allow for (more) mutability of transactions: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05153.html

Unfortunately raising the 520 byte limit would require a hard-fork; I don't think we're going to see that issue fixed. We may see it fixed in practice by a future soft-fork implementing a new form of P2SH, perhaps something similar to the original OP_EVAL design.

FWIW when I noticed the issue I pointed it out to some other devs, e.g. gmaxwell, who had never noticed it; I suspect the problem never occurred to Gavin when the P2SH mechanism was designed.

My initial versions of tree-chains all made use of miner validation; they were very similar ideas to how side-chains are meant to work. The problem is there were obvious security holes made possible by relying on miner validation, either to fraudulently steal funds locked in a 2-way-peg, or to cause outright inflation fraud and make money out of thin air. (in versions with mechanisms other than 2-way-pegs to move money from chain to chain) I also had versions that had neither issue and relied on fraud proofs, but then they raise the problem that if fraud ever goes undetected you can wind up with enormous and disruptive reorganizations.

Unfortunately I have no reason to think there is an easy way to copy Satoshi's original SPV mechanism in a scalable and flexible system; fortunately we do know that compact full-security coin validity proofs are possible, so you do not need to download the whole blockchain to have full-node security for your funds.

Tree-chains has a hard separating wall at the logical level, but not the data publication level. It's like how there's a hard wall between Bitcoin and Mastercoin even though they are both sharing the same blockchain.

Regardless of what risk minimization techniques you attempt, I highly suggest you try playing with my replace-by-fee-tools first to get a sense of how easy it is to double-spend, and for that matter, whether your techniques actually work at all.

Remember that it's always possible to double-spend with ~%10 probability by giving a non-standard transaction double-spending the input to Eligius first, followed by broadcasting the standard transaction to the rest of the Bitcoin network.

I think the most basic explanation of the difference is that in side-chains you put your trust in miners - if at any point there is a miner with enough hashing power to 51% attack the side-chain they can destroy it instantly, and often steal all the funds associated with it too. Now if a majority of all miners agree to mine your side-chain that may be ok and you won't be attacked, but getting to that point essentially requires asking permission from those miners if you want your side-chain to exist at all.

With tree-chains we create a global, yet scalable, blockchain publishing service that everyone contributes to and everyone uses. Everyone works together to keep that layer secure, and anyone can write code to make use of it. The disadvantage is that you can't rely on miners to verify for you - you have to verify blocks client-side - but that also means those same miners can't attack you without attacking all blockchains at once.

It's kinda like the difference between the telephone system and the internet: the telephone system relied on the underlying layer being "smart" and doing a lot of the logic for you. Adding new features to telephones meant changing that system and getting support from the phone companies. Tree-chains is the internet model: the underlying layer is very dumb and does very little, requiring fairly smart client software, however that means that to make new applications on top of that underlying layer doesn't require asking permission from anyone.

Worth reading for more details:

Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation
Tree-chains preliminary summary

Good to hear. Of course, you realize that the positions I have with Mastercoin, Dark Wallet, Coinkite, and others are advisory positions as well; as Chief Scientist/Chief Naysayer I am not involved in the day to day operations of any of these organizations. Now I hope comments like the following:


don't indicate any accusations of personal bias where I might be pushing ideas solely for the benefit of those paying me. So I'd appreciate it if you let Jeff know - I already did but some reinforcement of civility might be appreciated by all.

Along those lines, I've been working to diversify my income and clients sufficiently that would, say, Mastercoin fail I'd have no cause for concern. Similarly I've made a point of not taking significant investment positions in any of these currencies; currently the only non-Bitcoin crypto-assets I own in any significant quantity are about ~$3.5k worth of Litecoins, and ~$2.5k worth of Mastercoins, the latter only due to a misunderstanding about what compensation my contract with Mastercoin included. I'm strongly considering just selling off the latter entirely to maintain my independence, and either changing my contract or simply selling off future MSC as I earn them.

It's only reasonable to ask the same question of you: How is Circle compensating you exactly? Is implementing redlists/blacklists/tying transactions to real-world-identities in their plans? Are you going to financially benefit either directly or indirectly if technologies like that become a success?

Let's Talk Bitcoin just published my interview with them explaining why side-chains are insecure and bad for decentralization: https://soundcloud.com/mindtomatter/ltb-e104-tree-chains-with#t=19:04

You can easily do what you want to do with a soft-fork FWIW.

I think BitUndo is good for Bitcoin, and I think replace-by-fee is better: http://www.reddit.com/r/Bitcoin/comments/235zv5/why_you_should_mine_with_replacebyfee_a/

Any specs yet on what a "full node" represents?

In terms of actual capacity you're probably donating quite a bit more than 1.1% of the capacity of the network - for starters there aren't 11,000 full nodes reachable at any one time, more like half that number.

That's incorrect. We've been arguing for making WoT, CA's, and combinations of the two available to suit user needs. CA is fine when your security needs are low; when you're buying a coffee CA security is more than good enough. When you're moving $1k worth of Bitcoins you might want to double-check, $10k probably, and $1,000,000 you'd be downright negligent to rely only on CA's. Fortunately the same OpenPGP technology can easily support all these models.

Of course, remember that if you're writing Bitcoin software, it's really easy to be in a situation where millions of dollars worth of value are controlled by your software. That's why the Bitcoin sourcecode and binaries are protected by both OpenPGP and CA's.

Bitmessage isn't attack resistant whether or not it is used over Tor... As for your suggestion of a "proof-of-publication side chain", as always, it's a matter of security vs. cost. Just using Bitcoin itself gives you high security at relatively high cost. (though potentially not as high as you'd expect giving the complexity and inconvenience of getting coins to pay for a side-chain)


Again, we're talking about proof-of-publication here, not data storage. As I suggested above, think through how the idea could be applied to announce/commit sacrifices.

baddw & GLaDOS: You guys are really close; can you write up a clear description of how exactly a system like Counterparty could use P2SH^2 to achieve it's aim of proof-of-publication, given that we know storage of data is a separate issue?

It might help to try working through how P2SH^2 could be used for the more simple case of an announce/commit sacrifice first.

How do you know that hash is a hash?