This really sounds like an advert, it's offtopic for this development subforum too. If you were a single post account I would have nuked your post and banned your account.

Our curve has a cofactor of 1, which makes this easier... but it might be metter to describe it in a way that doesn't reduce security when the curve has a cofactor.  I'm not sure how to accomplish that though, since the normal measure of using numbers which a multiple of the cofactor won't work since the signer could potentially encode their sidechannel in the choice of the subgroup.

It seems like a great proposal to me.  It's basically the blinding scheme but it replaces a lot of impracticality with some interaction.  OTOH, the interaction is a major PITA for truly offline signing. No one wants to go back and forth to the safe twice.

I think we could make the interaction into a largely one-time setup... with a cost of some complexity:

Sequentially,
(1) Signer generates _many_ future k values, and builds a hash-tree over G*k. Gives user the root.
(2) User generates _many_ future blinding values, and builds a hash-tree over them to the signer.
(3) User forms a signing request, picks a blinding value, and gives to the signer the blinding value and the membership proof.
(4) Signer verifies the membership proof, picks a k value, combines and signs, and provides a membership proof.
(5) User verifies the membership proof and R consistency or otherwise discards the signature.

Now, though, you need to worry about nonce reuse, the signer must keep state to prevent reusing one of its nonces, which would be unfortunate. In particular if the signers state can be rolled back, it can be induced to reuse a nonce.

Ideally, you'd just form trees of 2^256 nonces and just have each message deterministically select its nonce. This has computational ... challenges.

I thought for a moment that perhaps you could just have two nonces for each bit in the message, but this results in straightforward linear relationships.  But perhaps there is some way to make it largely stateless.

I tried to give it a quick glance at least, but I'm unfamiliar with the language... and when I couldn't even tell how the private key was being passed to the nonce generation function I gave up.

Though it is the case that whatever glance I would have given it wouldn't really be enough to de-risk it compared to widely reviewed code... I figured a glance would be the least I could do. Well, seems not, a failed glance was the least I could do.

Unless you're using a seriously old version, if you're seeing errors like this you have a hardware problem causing corruption of your system state. You really shouldn't be using a system experiencing errors as a wallet, since if it glitches out while sending a transaction you could suffer unrecoverable losses.

It doesn't just cover up for conditions which can only be caused by faulty hardware for several reasons, one if that if a fault happens again later in a undetectable way it can cause you unrecoverable loss (as mentioned). Two is because checking that the computer did what it was supposed to do adds overhead and so there is only enough of that to tell if something is seriously wrong, not enough to tell exactly what. Three is that having enough data to recover would require more storage... the error you sound like you're seeing is a leveldb error in the chainstate database, not an error with a Bitcoin block. With the database corrupt it cant fix it by just downloading something again, it must rebuild it. And, forth and finally, recovering a single system from an impossible state--even where possible-- requires extra code which must be written and tested and could later cause bugs, these are real costs which are hard to justify for something should only happen on broken hardware (which is doomed no matter what the software does) so it isn't added lightly.

Sorry you're having problems, but as you note your other system doesn't have these issues.  A reindex should take only a few hours maximum (though if your disk is failing that can drastically increase the time.), here they take me under 2 hours though YMMV a bit due to system speed.

Bitcoin payment URLs allow you to use bitcoin without addresses. And generally without grievous security problems.

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.