Unlikely.  Power filtering cannot help you when the leak is so gross that it makes timing differences you could darn near measure with a stopwatch.

Though the device looks pretty interesting and would be good for applications where the software is already largely protected! But the invest page makes it severely smell like a scam.

Zero amount outputs can be spent; a bitcoin transaction need not involve any bitcoins-- this is part of the premise by which some of these embedded consensus altcoins hope to replace the Bitcoin currency.. They're non-standard to create, so they need miner cooperation.

Now I'm extra interested, since that sounds like a bug unless they're actually unspendable for some other reason.

Where are you looking? git grep on a current checkout shows me no bitconi, though the bitcon (a dreadful mistake that I've made a number of times myself-- had a laptop with a lossy keyboard) is still in src/qt/locale/bitcoin_da.ts though not elsewhere.

listunspent has nothing to do with the utxo set in Bitcoin core, its a wallet function.

You haven't provided basically anything to go on here:   No addresses where someone could attempt a reproduction, no list of missing transactions, no information about how you created this state (e.g. which side did you import keys into and how), no information about how the misisng scriptpubkeys are shaped.  I'm not trying to be snarky but http://www.catb.org/esr/faqs/smart-questions.html  covers some important life skills which too few people are taught and which you might benefit from!   There are basically only two possible answers to your question:  "I have no idea and you've not given enough information to figure anything out"  or "This sounds like an already known bug, but you haven't given enough information to be completely sure".  I'm not aware of any known bug that sounds like this and likely would be aware of it if there were a known one on the Bitcoin Core side.

Why are you assuming this is a Bitcoin Core bug?-- could it be that btcd is displaying txouts that have no business being in your wallet (e.g. weird scriptpubkeys or already spent txouts)?  (I'm not arguing that it isn't, or that you don't have a reason to-- you've just not specified that reason whatever it is, and to investigate I must know!). It would be somewhat surprising if there were some systemic reason for entries to now show up in listunspent and no one were reporting it, but there is always a first one.

Do you have a reason to believe this just isn't missing change addresses and transactions involving them?  Try locating a missing entry and run validateaddress  with the address the missing entry has on the wallet that is missing it.

If you send me the _whole_ listunspent output from each, and a precise description of how you created the wallets, I'll look into it-- with that I should be able to reproduce the behavior.  Feel free to use PGP to preserve your privacy (and that of those you've transacted with).   If you're unable to share this information with me, I'll still be glad to help, but it will be much harder.

Thanks for taking the time to formalize your thoughts here.

I'm surprised that you didn't make any reference of control theory; which speaks substantially to this subject. In particular stability analysis with 'non-linear load' (e.g. miners that turn on and off based on profitability) is a critically interesting subject.

I would have liked to see more elaboration on strategic behavior.  Most schemes I've considered that had 'accessible non-linearity'  have possible mining strategies to increase income for a given amount of work (e.g. mining in fast/slow bursts-- forget what it does to the block speed; consider how much income you mae); I've assumed but by no means proven that this was true for all non-linear schemes.  E.g. the attacker doesn't care about manipulating the height so much as getting the most height done per unit work.  (And this is the part that control theory really doesn't speak to).

Another area is security against isolation attacks. The current system's slow, capped, linear adaptation requires considerable cost to create a 'plausible' fake blockchain for a partitioned victim. Faster updating schemes generally tend to be much weaker.

Were I a reviewer I would have squaked a bit about your comments about bitcoin's "exponential growth", we _know_ that the huge ramp in the last two years is from catching up to current technology and Bitcoin's wild increase in popularity and value. Right now the hashrate is stable to growing slightly, but perhaps slightly falling ( http://bitcoin.sipa.be/growth-10k.png ).  The whole premise of wanting to understand how things grow under exponential growth is reasonable;  but we have no evidence or physical basis to argue that the system can grow hashrate forever ("moore's law" is not a physical law, it's an observation about the density of transistors on cost effective process;  ... mining is far more energy limited than density limited though there are relations).   I don't object to the area of analysis, just that you've overplayed the premise somewhat.

Another interesting area is considering "cross effect", e.g. if you use a the null predictor model an exponential reality is pessimal. Well whats the pessimal reality with the exponential predictor? What if about a first order linear predictor? etc.  It would be interesting to see a matrix of "true system" vs "model" and how bad the results are. I know in other optimization problems I've faced the "stupid filter" also happened to be the most general and robust against model errors.

Instead of taking a 'proportional' control-- did you consider just including an integral term?  It would be interesting to know how much better the unpredicted change is if you're just adding back in a small amount of the total error so far. If so, I missed it.

The comments on consensus horrified me a bit:  It is not any harder to write exact numerical software, certainly no harder than 1000 other things which must be done exactly right in a cryptocurrency. These are cryptosystems after all! Every modern video codec and audio codec had normative numerical code...  The suggestion to commit to a value and then 'check it' with an error check would almost certainly leaves the system wide open to attack. Keep in mind an attacker can drive the system into a state that reveals very small differences between implementations.  Error analysis on non-exact code is fiendishly hard and there are often library/compiler bugs lurking in non-exact math code. Basically that suggestion takes a probably similar in difficulty to every other element of cryptosystem implementation and replaces it for one which is much harder.  

Doubly so because other considerations probably limit the range of your correction (otherwise partitioning attacks, incentives, and effects of noise pushing things wildly out are worse). This means your function probably only has to operate over a known, limited range, and some simple integer polynomial approximation is probably fine.

Actually, from the computer the Trezor is connected to itself (after all, the point of the Tezor is the assumption the host computer is compromised); nearby would be an even more impressive stunt--  in terms of nearby but not connected; that would better be done with a software defined radio receiver (e.g. not merely a remote compromise).

All of that is a long shot, but thats the annoyance about defense; you have to defend against all attackers, and an attacker may spend a lot of time and resources on a single valuable target.  It's quite hard to be confident that you do not have an exploitable weakness. If you're sure you're secure you're probably not being creative enough.

It isn't connecting to the jtag is easier than the power analysis.

But-- not quite the same, it's conceivable that a sufficiently creative attacker could do basically the same power analysis attack just by recording EMI picked up by the soundcard in the computer or via RF emissions from the device. (It's apparently quite easy to pick up noise from the trezor from across the screen with a radio receiver).  People who've tried this have been frustrated by the extreme amount of noise put off by the screen and power regulators, but sufficiently advanced DSP may overcome it.

You haven't said what you wanted to do with it.  Bitcoin's system can already accommodate this, just truncate the public key hash further.  ... or did you want encryption? or something else?

I suggest taking their claims at face value and asking them why they're behaving unethically; make them clarify that what they're doing isn't actually an attack.

They didn't, and it didn't say they did.

All this is saying is that they can put data inside OP_RETURNS which other malicious software can act on.  This is one of the problems with having non-trivial side-channels for non-bitcoin data. The complaint is mostly hype.

Perhaps the real news should be "Kaspersky says they believe they know a vulnerability in Bitcoin, but they failed to responsibly disclose it to the developers and instead wrote press articles on it".

It's the same security model that Ripple was initially advertised to have, but which didn't actually work in practice. The mechanism and conditions appear to be slightly different, and the requirements actually (somewhat) defined, but the fundamental concern remains.

I pointed out back in 2013 that the result of the OpenCoin Ripple model would either result in centralization or a total failure of consensus; and pushed them to formalize their requirements and to specify a procedure that might actually cause them to be met.  They didn't. When Ripple was deployed the outcome was centralization, and when they repeated the experiment with Stellar the system spontaneously failed.

Just as with ripple back in 2013 the new Stellar proposal is unable to answer the basic questions about how we can know or guarantee anything about the security of the system.  Mazieres and Vitalik describe it as leaving it up to the market and think it will work out. I think it would better be described as leaving security up to chance. And the chances don't look good: leaving it up to the users to ensure a safe and decentralized topology has already failed in practice with a highly similar system _twice_.

I pay attention to these things because I hope to see useful things invented and deployed (for their own sake, and so I can use them in my own project); I also pay attention because I'm concerned about blow-back. _Currently_ people are free to do what they want, here there is tremendous information asymmetry and a host of incentives which are at odds with the public interest (including the fact that the few people like me who can clearly see the problems, have every incentive to say nothing at all; much less enough to be anything but a reed in the wind against a massively funded PR effort); and these efforts raise problems across several domains of law.  The result may well be some crazy efforts to regulate the space as a result, which would harm everyone.

Trustworthy? Not as far as I am aware of.  There are various pieces of software which have never been subject to peer review, have no tests, have no comments, could not possibly be free of timing sidechannels, etc. Several times people have posted things in this subforum which were outright backdoored (I'd link, but I delete the posts); exploiting the fact that most people don't have the time or patience to audit them. (Of course, all this can also be said for the various cloud services, plus they have a whole host of additional potential weaknesses.)

I wouldn't expect to find one any time soon, writing software in PHP and Python is incompatible with avoiding timing sidechannels or leaving around private key data in memory (not to mention slow); so it's not a first choice for the development of conscientious cryptographic software; and it takes a tremendous amount of work to produce something that deserves confidence.

Signing is even harder, as there have been a large number of implementations out there which were outright broken; using non-cryptographic RNGs that leave the private keys exposed to recovery.  If you didn't require the software be PHP/Python, only callable from it, bitcoin-tx command-line tool in Bitcoin Core can be used for signing, and doesn't require having anything running.

Thanks. You might want to change the ":" to a "." since its easy to misread the title, I loaded this thread all ready to chew you out and disagree with you; only to realize that you were saying the opposite of what I expected from the title.

"Paper wallets" have been the subject of a bunch of marketing push from a couple different angles. They're fun, some people have a commercial interest in them, they make for good security theater. But seldom do they make for good security.  Ignoring malware the number one risk to people's bitcoins is loss/destruction, and often the paper does particular poor there without special care. (I've now dealt with two people that lost substantial amounts of bitcoins due to paper wallets and water damage!).

An extra data point is that the web services you see are cryptographic crapshoots.

They have random unreviewed crypto code, written by someone who's never done anything like it before or copy-pasta from someplace else that had no review. I've seen a fair amount of stuff that was so broken that you had to have at least four kinds of cluelessness before you would think that the approach taken had any chance of being correct. It's bad enough that you can't ever find intentional backdoors because the honest mistakes are so crazy and so common that an actual backdoor would just hide in the noise.

Not that this problem is unique to the paper wallet space, but it seems to be especially bad there...

The web and JS is already a very hostile environment for writing secure cryptographic code-- JS has a lot of subtle, browser specific, implicit behavior and "action at a distance" that makes it hard to review, review is just not a cultural norm for most web software, the browser execution environment fundamentally cannot provide constant time operation or data leak free operation. ... and basic "key generator" and "signing" code is fairly easy to do (at least if you don't care to do it very well) and a fun little project.  Then these pages are loaded without HTTPS across an untrusted network, through an untrusted CDN from an untrusted server, hosting files for an anonymous and untrusted author.

A bunch of things that would be better described as "Jonny learns to code" are finding themselves in production use with hundreds of thousands of dollars flowing through them, because the end user has no means to judge the integrity of the work or the process that produced it. (And often the authors themselves have no idea how risky things are, or worse-- developer confidence can be inverse related to competence due to the Dunning-Kruger effect).  I'm not sure what to do about this in the ecosystem; it's pretty clear to _me_ when some piece of code or its process has no evidence of meeting even the most basic standards, because I live them every day, but I have almost zero desire to go play gmaxwell-the-destroyer-crusher-of-dreams crapping on other people's project with unsolicited and often unappreciated reviews (it's amazing how hostile some developers are when you point out their stuff is actually broken, not just theoretically ugly), nor do I have the time to do it all myself.

Been proposed before, we also looked at using it in p2pool but turned out not to need it there.

I think you're over-complicating it. You can just allow miners to disclose an address message in their blocks, could be them, could be some other node they like. It would give another view of the topology of the network, which would be helpful.

A key observation is that the ordinary non-partitioning security requirements mean that you only need one honest peer (but, sadly, privacy requirements mean you would really prefer no dishonest peers).

Absent authentication in the transport, however, a network attacker can still partition you even if you get node pointers from blocks. This diminishes the potential benefit.

Private keys have a flag to indicate if they're to be used with compression or not, as the compressed/uncompressed pubkeys are distinct; the flags are needed to make the private keys distinct too.

If someone can't give you their pubkey then they almost certainly cannot sign for a multisig. You cannot just go and grab random keys from people and expect them to be able to use them in random ways!   Thats handing someone a safe and saying "what do you mean you can't open it? it's keyed with a fragment from your DNA; you've got like a trillion copies of that inside you!"; beyond the basic bit of protection from doing something boneheaded there, using hash160s there would basically double the amount of data needed in the blockchain for a multisig transaction; and would much more rapidly run into the redeemscript size limits.

For (2) thats up to the software you're using.

APIs like that can feed you completely bogus data, at their whim, like payments that never really happened, causing you to give away goods.  Even if you log the results, you can't even prove to third parties that the API lied to you.

Services like that often use third party 'dos mitigation' services that they had their SSL keys over to (and, of course, the security provided by SSL is paper thin in practice).

Like many things, these things are perfectly secure if you have nothing to lose... otherwise? not so much.

Bitcoin was design to eliminate the need for this kind of trust; too bad that so many have rusted to rebuild it in Bitcoin, rather than contributing to make the trustless infrastructure better meet people's needs.

It's actually quiet easy right now.  Use the invalidateblock rpc to kill an old block. It will disconnect the blocks after it, one a time backing off the tip... and put the transactions in the mempool. (some set of the transactions will fall out because they're descended from disconnected coinbases, but most will be in there.)

Use reconsiderblock to fix your node...

This may get broken in 0.11 since Gavin has a PR to cap the mempool size during reorgs.

Not that we're aware of, all the involved algorithms should be log() scaling. 4000 is not very large either. I've fairly recently tested with a good month's worth of blockchain in mempool at once. (Which does indeed cause some slowness, but its orders of magnitude more than you're talking about...)

uh.

$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
{
    "size" : 320,
    "bytes" : 562732
}

or your friendly neighborhood debug console.

Since you weren't aware of the command, I'm guessing "seeing it" means bc.i-- take that with a huge heap of salt.