I checked the sourcecode they've published at https://github.com/trezor/ - it's not totally clear because they haven't published the actual device firmware, but the communications protocol lets the TREZOR fetch both transaction inputs and outputs. This would let the TREZOR build up that transaction incrementally so it doesn't need more than a minimal amount of ram, and of course let it fully verify each txin.

Yes you are missing something.

The way Trezor works is that the untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.

I am an electrical engineer, and frankly what you're saying is crazy.

If it's so trivial to implement then where is your proposed implementation and BIP? It could be re-implemented fifty times through rejections and objections and still be less work that the true work associated with all the testing, wallet implementations, and alt-implementations associated with this idea.

Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.

This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...

Custom silicon is the problem: how do you know what it's actually doing?

The sweet spot is probably 16 and 32-bit microprocessors: fast enough to handle crypto without pain, small enough that hiding malicious features is very tough for the manufacturer, and cheap enough that the community has a chance of auditing the actual shipped hardware and firmware against the claimed design.

Microprocessors in this class don't have significant problems with txin's provided they have a reasonable interface to the PC, like USB: just hash the supporting transactions incrementally. With well-designed hardware the fact that the device is connected by USB has no security risks and can be easily audited. (FTDI's USB<->high-speed-serial chips are a good option for the truly paranoid)

The scalability of Mastercoin - whether or not it uses merge-mining - is a very similar question to the scalability of Bitcoin itself. I'd be interested in taking this on. What kind of timeline do you want an analysis finished by?

You'll have more luck pushing for this by developing a multisig wallet implementation and getting people to actually use it first - P2SH required a painful soft-fork yet years later it's still hardly ever used, making people question the value of new features. P2SH was something that everyone was supposed to be using by now because of the "obvious" security need; you're proposed reason for a soft-fork and associated system-wide risk is significantly more niche.

Like it or not the amount of money that can be lost for a single consensus bug is staggering and gets bigger every day.

FWIW Litecoin will need to undergo a soft-fork soon to finally get height-in-coinbase implemented - talk this over with them, specifically Warren Togami.

Actually the only measurement you need is the orphan rate and the block interval:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03274.html

Note that's actual block interval, not steady state, an oversight Michael Gronage corrected for me in his reply. Of course this doesn't give you detailed breakdowns of latency and bandwidth, but given the consolidation of hashing power the measurements Decker et al. made on network wide latency/bandwidth make a tonne of assumptions about topology that if not already inaccurate, won't be in the future.

Calculate it based on the total sum size of the transactions, not the number of them.

CoinJoin transactions are slightly smaller than non-CoinJoin because all parties can share the same transaction header, and thus are actually cheaper than the alternative.

I'll say....

So, if Luke's an anarchist, what am I? I'm trying to think of a stronger term for anarchist and I'm failing, and I haven't even begun to try to figure out how to describe Amir...


Anyway, seriously speaking I wouldn't worry too much about the anti-address-reuse patch right now. It's a very good temporary nudge in the right direction - I fully support Luke for implementing it - but it's against miner incentives to do it by leaving tx fees on the table. In the long run I'd be really surprised if the idea becomes all that common, and if it does, adding anti-anti-addr-reuse to MasterCoin is always possible by community agreement. If it's not much work to implement, go for it, but I've reconsidered a bit on this topic and right now my gut feeling is don't worry too much.

What you do need to do is make sure that MasterCoin tx's work fine no matter how many blocks separate them; I seem to recall something about six blocks at one point in the discussion? The number of consecutive blocks by any one miner is unbounded after all.

edit: BTW this applies to ideas about merge-mined chains too: you can always implement that later if they're needed. Focus on getting the core functionality and community that you think makes MasterCoin worthwhile up and running now rather than getting distracted. You gotta remember that MasterCoin transactions will tend to be more valuable per transaction than Bitcoin ones, so it won't be your users that are outbid first in the transaction fee auction.

I think the term you're looking for is "Best Practices", perhaps "Dark Wallet Best Practices"

Ha, the Dark Wallet Certification thing? You are so incredibly wrong:


Emphasis mine. It's going to end up as some fancy wiki page or manual or something with a bunch of strongly worded and not so strongly worded recommendations. I'm not going to be surprised if there's multiple competing versions. Some respected developers might go and publicly state that they believe "Electrum v1.2.foo" complies with all the recommendations and isn't trying to steal your coins and sell your data to the NSA.

You know, if a bunch of anarchists can't meet up in some commune in Italy and collectively agree on that, I dunno what it takes to be decentralized these days...


For the sake of argument, lets assume Mike is a android built by the NSA to infiltrate us all.

Do you think you're going to to a better job of stopping said Bitcoin-development subverting android by a: complaining, or b: getting shit done.

I'll give you a hint: someone else already did the job of complaining much better than you're doing. Lets count that: four tightly written paragraphs, one verbatim quote, cross-posted on two forums, and results? Over three main threads we've got 32k hits and 811 replies on this forum alone, including responses by people worth listening to like Adam Back and Gregory Maxwell, an article on CoinDesk, CoinJoin bounty is up +8 BTC and the Dark Wallet campaign is nearly fully funded - that's some effective complaining. Not so effective computer security, but yeah... I'm pissed off about that.

You on the other hand, you're just annoying people like myself who are actually flying halfway across the world in two weeks to go make CoinJoin happen and make Mike's misguided ideas about blacklists irrelevant. So I dunno, unless you want to surprise me by showing me that you're good at getting shit done, go away. Delete your trolling posts while you're at it.

And you know, if you want to get better at it, you can start by saying things that actually make sense.

Touching on gmaxwell's point about whether or not features should be forced, I think we can divide the features into two main categories:

• Individual protections: Anything where the strength of the protection is not dependent or is only "linearly" dependent on how many other people also use it. For instance local encryption of wallets, encryption of p2p communication channels, etc.
• Communal protections: Anything where the protection is made significantly stronger as more people use it. Examples include CoinJoin, CoinSwap and mix networks.

Now what really distinguishes those two situations is that for the former, whether or not everyone adopts the same standard doesn't matter all that much, so a certification should be about what goals were achieved, not how.

However with the latter, there are really good reasons to try to get as many users on the same underlying protocol. For instance with CoinJoin/CoinSwap, you want the anonymity set to be all Bitcoin users, not "recent versions of electrum". This is especially important because CoinJoin won't get used if it's not convenient - the more people using it, the faster a join can be arranged and the more likely a casual user who mainly just wants his transaction to go through will be protected.

That doesn't mean every CoinJoin implementation has to be the same, but I do think we should make sure we come up with a lowest-common-denominator form of CoinJoin that is reasonable for any implementation to support and participate in. In this case I think we want the standard to eventually specify that common denominator explicitly.

...and you know, while we're on ethics, trying to sneak web-bugs into forums is bad, but hacking into someone's private, personal, encrypted, email as well as their computer is disgusting.

Mike's partly mistaken anyway, as I said on reddit the attack on SPV nodes was in that they give very little privacy and can easily wind up revealing the contents of your wallet. jdillon and I eventually decided it'd be worthwhile, and most ethical, to put up a fake website claiming to be a company running many different Bitcoin nodes and explaining how that would let them get data to track who owned what coins - something blockchain.info already does to an extent. It would have been a good warning to the community about what privacy their wallets actually have; we need better privacy protections in Bitcoin wallets given that someone probably will do this for real sooner or later. We did discuss actually doing the attack, but decided against for ethical reasons.

In the end we never even went that far for a few reasons, including that progress was being made, and public knowledge of the privacy issues seemed to be improving; even a simple website has ethical concerns too.

As for the DoS vulnerabilities, jdillon wanted to demonstrate how SPV is fundamentally flawed right now in that there is no way to distinguish "real" users from a DDoS attacker and the resource consumption is asymmetric; no amount of scheduling that fix that issue although it helps related issues and would help in conjunction with design changes. At the time we were having a very hard time convincing some people, Mike included, that the issue was real, and solutions that could have fixed the design were getting a lot of push-back. But on top of that there were other vulnerabilities too that affected everyone and made other types of attacks possible. So I told jdillon to hold off so the easily fixable problems that he wasn't aware of could be fixed first, and the decision about whether or not the problem needed to be demonstrated to be reconsidered at a later time.

Myself I spent a lot of time on the issue with a small group of devs, and while it's far from perfect, the 0.8.5 release is significantly improved by those efforts. And yes, I did do a type of attack on Bitcoin mainnet. After seeing mainnet nodes begin to be affected after a few minutes I stopped.

What you think of the ethics of all this is up to you, but it seems that the desired end result of getting the people involved to change their minds is being achieved. I'm not going to claim either myself or jdillon have always gotten the balance right between disclosure, demonstration, and delay, but he never made me question his sense of underlying ethics and end-goal of achieving a more secure Bitcoin in a responsible way.

I've probably thought about this issue more than almost anyone with my work on fidelity bonded banking, and even ZeroCoin can be made fully transparent if you choose too. The key thing is that a: zerocoin has a public list of all spent coins, which lets you know when a coin was spent, and b: it's still possible to prove you were the one that spent a coin. Auditing in that scenario comes down to you publishing proofs of what coins you have spent in a provable public manner, and transparency is achieved by the fact that in a well-designed system you can't get away with lying about your transactions. You can fail to publish your accounting logs, an act that is of course very suspicious, but that's actually no different from the scenario with pervasive coin mixing: either way where the money went is unknown.

When it comes to receiving money, no amount of auditing can prevent you from taking money in behind the scenes, but there is no way to do that and also hide the fact that you are doing that from your sender. In this case the solution is actually identical to the non-zerocoin solution: publish in advance what addresses you accept payment on, and anyone can scan the blockchain for payments to those addresses.


Agree from an engineering point of view; ZeroCoin's requirement for a hard-fork and many lines of new code using complex crypto is a risk Bitcoin shouldn't take. Coin mixing done well has very close to as good privacy, and can be easily fixed if it doesn't work.

Well... who hacked the bitcointalk forum? inputs.io? etc. etc. etc. Lots of unknowns, and that's on both sides of the we are or aren't being played thing.

See, my exposure has been that like the rest of us, they're humans too.

One of the more interesting comments about the downfall of the Silk Road was that the social environment of being DPR is incredibly unhealthy - who could DPR have as a friend to talk too after work? jdillon and I often talked on OTR real-time chat - AFAIK the only person he did that with - and it's certainly easy to imagine wanting to open up a bit about who you are. Just human nature to want to connect with like-minded people and communicate.

You could be right of course, but I don't see anything suspicious about it myself.

That text about libbitcoin was posted by myself on the foundation forums; I just thought jdillon would find it interesting.