You could save both of us some time and just send all those funds to me directly.

You know what you're asking to do is "not smart"... that it's just going to directly result in the funds being lost to thieves who simply impersonate everyone. So why do you still seek to do it?

How about you?   No one but you chose to use counterparty or blockchain.info.  I'm sorry to hear about your loss, but this is what happens when you use unreviewed cryptographic software-- especially things which have already been publicly criticized and have even suffered similar failures in their past.

Vanitygen has split key generation built in and has for years.

I consider this discussion a huge red-flag.  You should never let a third party generate private keys for you.

Uh. ... You realize this is a massive upgrade right?  Before you were trusting all of the hundreds of parties that could be MITMing your connection, and after you trust fewer (just bc.i their staff and contractors, cloudflare, and any certificate authority or someone who has compromised them or received a sub-CA cert from one).  The certificate issuer has no active role in the connection you make, their role was simply to one-time sign a public key bc.i presented to them and attest that it really was bc.i.

Writing your own software has its own risks. I wouldn't trust crypto code that hasn't been peer-reviewed, even if I wrote it myself.

And should have been obvious to anyone who has implemented the cryptosystem too,  if k didn't have to be secret/unique you could just make it a parameter of the system and eliminate r and halve the size of the signatures.

I have to say that I miss it, but ... then again I wasn't moderating it.

There are a lot of OKAY posts by newbies... and also a lot of awful ones.  Maybe the newbie jail only really helped by decreasing new users in total-- if so, then it was a loss and we're better off without it.

I don't mind deleting the complete garbage, borderline stuff is a bit more annoying.

I think that it's better to take a bit more garbage than risk turning away good new users.

You might want to try opening a thread in marketplace and seeing if you can pay someone to do it. Otherwise you probably could have asked in the BTCGuild support thread.

Yup agreed. But multisignature works today, and is secure under basically the same assumptions (that one of the two is not evil), and can protect against some additional failure modes e.g. someone steals the offline signer. So thats what I currently strongly recommend.

You really shouldn't use anything from "brainwallet". It's had multiple serious vulnerabilities in the past (such as using an insecure RNG).  Its anonymous author got his start creating it after being frustrated that not more people were using H(password) strings;. More recently the creator was complaining about being broke, then a few hours later asking in #bitcoin-dev for help using our crypto library to create a very high speed pubkey generator (read: brainwallet cracker).

In general you should _never_ use a "brain wallet" (at least of the kind that site promotes), humans are remarkably bad sources of randomness and often when you think you're being "random" its actually making you more predictable. Human memory is also fairly fragile and many people have spontaneously forgotten strings they used almost every day (and if you use your brain wallet every day you're going to manage to leak it)... and the structure that makes some strings easier to remember make them faster to search.  Keep in mind that you may have attackers with FPGA (or asic) farms testing billions per second.

When a network service is compromised and their password database is stolen and people find out that it didn't use salted passwords everyone is up in arms calling them grossly incompetent.  But brainwallets are the ultimate unsalted password ... the database is inherently public all the time, there is huge value attached, and it cannot be effectively salted (if it could: just randomly generate a key, encrypt it, and save that instead of the salt...).  And yet, people who deploy unsalted passwords on private servers that later get compromised (as seems to happen to all servers eventually...) find it hard to find future employment, but in Bitcoin creating a crappy JS or python "brainwallet" tool and you're crowned a big brain on the conference circuit. It's a strange world.

::Sigh:: Again?  https://people.xiph.org/~greg/21mbtc.png

Really the limitations of the security model for that kind of wallet only start with the JS substitution/injection attacks. The fact that even if the software is perfect it depends on honest data from the server... You can rob someone just as well by making them think they've been paid when they haven't been as you can by stealing their private keys.

It would require a conspiracy with the host device.  Such a conspiracy can simply not be prevented... e.g. if _Every_ device you have is lying to you about what transaction you're authorizing you could be authorizing anything.

Yes, it requires schnorr signatures. Which is why it's not in use yet in Bitcoin; though we have soft plans to adopt schnorr signatures for many other reasons in any case.

I think it matters greatly... you're certainly not going to see a trezor like device generating such at thing.  And, as you noted... the ZKP has freedom and can create a side-channel.  (and I believe thats inherent if the zero knowledge is perfect). On the plus side, you can prevent the attacker from seeing the proof, which would help.

To create some perspective. The creators of Trezor did not want to use a strong KDF for their user provided keys (which are likely to be brain wallets) or (initially) derandomized DSA all because of performance constraints. Any ZKP for general computation is going to be millions of times more costly in cycles and ram.

I'd love to see someone create it, none the less!

Right, so if the users separate computer is in a conspiracy with the device all is lost... which is why multi-signature is a good tool for use today (or blinding would be one, if it were available yet).

Well not pedantically. Its most logical to consider the compressed/uncompressed flag to be part of a private key... in that logically a private key is _all_ the information required to create a pubkey and to prove you created the pubkey.  Of course, if you permit twiddling arbitrary parts of a private key I can create countless pubkeys. There is a third state too, for that matter.


It isn't the case for conventional EC with conventional serializations, but it's also the case that some public key systems are not unique. E.g. if we seralized the points as Jacobian coordinates there would be ~2^256 distinct pubkeys.

The check twice is assuming you use a second independently sourced device ("audited via another offline device"), sorry that wasn't clear. Certainly doesn't protect you against an insider! Wild to hear about that attack.

As several people have pointed out, only one of these is _technically possible_ because Bitcoin is a globally consistent consensus system implemented by machines that execute implementations and not prose specifications, regardless of whatever would be considered "best" in a world of frictionless spherical cows unbounded by constraints like the possible.  (I am assuming you're using a narrow definition of "standard": An implementation is merely a infinitely precise specification constructed for the benefit of machine enactment, after all. That you present it as a choice must mean that you're defining a "standard" as something inherently too imprecise to act as a concrete embodiment itself.)

It's easy for me to suffer some frustration when people continue to just repeat "but standards are good!" without demonstrating an understanding of the specific technical and political considerations in the problem space, and also while retaining a very narrow definition of what can constitute a "standard", "open", or "transparent".

Bitcoin is broken, insecure, and worthless if the machines implementing it are not able to immediately achieve globally consistency. This is a security requirement of the application domain: If the behaviour of the systems and the specification disagree, you _must_ change to match the systems or be left behind and have your funds stolen.  It's not that I don't think standards are important-- I've been involved with the IETF for many years, and attend much of the meetings and contribute to a number of working groups myself; but Bitcoin has specific technical and social requirements that make standards documents weak (even, at times, counter productive) tools when talking about the behaviour of the established production system.  Unlike TCP, SMTP, HTTP, etc. Bitcoin doesn't simply need to be somewhat inter-operable: when it comes to consensus behaviour all of the systems that constitute the network must behave in deeply identical ways. If an attacker can expose a widespread inconsistency in behaviour, however small or burred, the system faults globally and funds can be stolen even from people whos own systems are not having problems.  If the system were not demanding of consistency Bitcoin would be insecure in other ways instead.  This is just a technically harder challenge than faced by other protocols.

There is another layer to this--  Standards process ultimately rest on the politics of mankind. Most standards efforts are remarkably malleable to politics, easily bent by monied interests to their own ends... as elegantly demonstrated by some of the backdoored cryptography thats made its way into various standards, or rent seeking patent traps that required in many other international standards. And even as we speak, various groups who have little understanding of Bitcoin technically or involvement in the ecosystem have been holding workshops to "standardize it". It may well be that the people behind these efforts are completely innocent of ill-intent (beyond, perhaps, a little vanity and self-promotion), but levers that create a point of control will be exploited in the future if they can be exploited; doubly so when the people involved do not understand the risks.

Bitcoin was created to build a system whos behaviour was more deterministic than is otherwise possible in a world where political expediency can sometimes override "constitutional" guarantees. While it's useful for people to discuss Bitcoin, and nudge it here and there, without the ability to largely elevate itself above political expediency, Bitcoin serves little purpose. I think we should all support efforts to communicate better about Bitcoin, including building better descriptive text to build an on-ramp to a more complete understanding and aid people who only need an informal view. I've contributed time to help improve the developer's guide, help publish BIPs, etc. But there is authority and autonomy risk from crossing over into the realm of proscriptive text that ultimately seeks to control the system rather than the system controlling the text. This is why, for example, the BIP process as a whole is intended to be rather descriptive and there are BIPs for a number of things that quite a few experienced engineers in the space consider to be seriously ill-advised.

Another way I could present your question is "Should a human readable but inherently ambiguous definition requiring politicized interpretation and adjustment drive the definition of Bitcoin? or should Bitcoin be defined by math... even though math is not always easy to read?"

I think the Bitcoin community is smart enough to realize this, and not be deceived by people peddling a political and inherently unrepresentative standard process "driving" Bitcoin to change out from under them and potentially against their interest as "transparency" and "openness",  when it's really is anything but... making something more readable at the cost of being well defined may not be an improvement to transparency at all. A lot of contemporary standards processes could learn a lot about openness, equality, and transparency from Bitcoin. Even inside the IETF it's not too uncommon to hear the sentiment that the IETF has somewhat lost its way, now too influenced by politics and personalities than by running code. In the context of conventional standards this may just be a source of unfortunate inefficiency and avoidable failure, but in the context of Bitcoin the risk is more fundamental and so we must step carefully.

When someone is interested in gravity we can describe it informally, but when they want or need to really understand it-- in some way that has consequences-- we don't pretend that we can shy away from precise formal descriptions-- to do so would be to undermine engineering, and it would result in people dying. We certainly don't seek to "specify" it with prose and expect the universe to obey. Nor should we with Bitcoin. Bitcoin is the physics of a virtual universe, if you will. And like actual physics there is no replacement for a precise, formal, description--- especially if you're in the business of building the machinery of that universe yourself.

What I was talking about there isn't about plug-ability or extensibility; it's orthogonal to it and wouldn't itself offer any additional flexibility. The motivation there is being able to achieve absolute consistency in the parts of the system which MUST be absolutely consistent while still allowing for multiple implementations by reducing the surface area where things could go wrong.

The kind of flexibly you're thinking of might also benefit from some of the same tools... but a consensus system like Bitcoin has some pretty incredible overheads that preclude a good bit of application space by their very nature.

It wouldn't: You'd use a authenticated data structure so that all the input could come from an unverified domain. It could fail completely but it would know it... even a not found would be expected to prove non-membership by providing fragments for a search query that failed against the current root.  The UTXO doesn't even need to be committed in the blockchain for this to work, e.g. the bytecode machine could just keep track of the root itself.

(If you wanted to be especially paranoid you could use path-oram to make sure that there was no visible access pattern or data sequence outside of the sandbox thta was common on multiple hosts which could cause a systemic failure).

The communications are already speced out in reasonable enough detail that multiple people have implemented talking to it from just the documentation. (e.g. from he developer guide and Bitcoin Wiki/

You're accusing people of being dishonest?  Really?  Try engaging in a little professionalism. Next time someone gives you an explanation you don't understand, you could try not accusing them as dishonesty as a first step. It certainly doesn't motivate people to spend their time educating you on a subject about which you are clearly ill-informed when you take that approach.

Sometimes people perceive value incorrectly. It's not that the code is "fine" its that for the normative operation of a consensus system it's all that actually matters. Additional informative documentation is useful too, and people have written a fair amount of it.

Funny, I don't see how thats an example of better peer review of the protocol at all: It requires only an understanding of the system at the level in the original Bitcoin whitepaper (which has been available since 2009). OTOH, I've used that work before as an example of how academia needs more peer review from industry-- because that design breaks decentralization which is the whole point of Bitcoin, and Amiller proposed a very similar design (and arguably better, since there were some additional attacks it resisted) back in 2011 which the work should have cited.

A bytecode simulator, like the JVM. One intentionally constructed to be very simple in order to avoid the extreme reimplementation risk in consensus code.

The non-random rng would have also resulted in giving unrelated users the same keys. It didn't just effect signing.

Go look at what a blind schnorr signature looks like mathematically.  Without knowing the blinding factor the signer has zero knowledge about the resulting signature... it could literally have any value, so they're unable to grind it or pick it in a trapdoored way.

Sure,  add maxconnections=16  in your bitcoin.conf to limit yourself to 16 connections, for example.  If you want to go below 16 or so, I'd recommend you run listen=0 instead (so you'll only have outbound connections).

I'm planning on working on a number of bandwidth reducing options for the next major release after 0.10.

0.10's parallelized block download will also reduce the variance in bandwidth usage that other nodes on the network experience.