Except the issues with poor cryptographic security Mike is talking about have only been observed-- so far-- in tools written in Java, Javascript, and Python in our ecosystem. None of these are low level languages.

Unique signatures are trivial and exist in many forms (e.g. the BLS signature scheme is automatically unique); They all have unacceptable tradeoffs: Huge increases in signature sizes, much less mature cryptographic assumptions, greatly increased verifier computational complexity, patents, one time use, lack of review, etc. (or usually a mixture of all these)

Picking a signature scheme based primarily on your ability to suppress side channels sounds like obsessive micro-optimization.  While desirable, we have multisignature already, which is arguably better than sidechannel suppression, and doesn't excessively compromise the many far more concerning criteria.

Huh??!  No, I believe I was the first person to promote it in this community.

Perhaps there was confusion over this point:   It doesn't actually solve the problems you're talking about. The very same incidences caused the private keys to be just as insecure.

This doesn't mean that a strong derandomized DSA isn't a good idea, but it does less than many credit it for.

No it wouldn't, adding a new signature system is just a soft forking addition, of a smaller scale than we've made several times before (e.g. with the introduction of p2sh).  Not something to do lightly but not that big a deal.

But blinding alone isn't enough, because you actually want the signer to see the message (because the signer needs to display what the message will do to act as an independent check or to enforce business logic).  Though there is probably a very narrow and very efficient ZKP that can be used to unblind only the message.

Yes/no. I thought it was nice at first but then I realized it's no better than my two move scheme, I think.

The signer knows the resulting r that will show up in the signature so he can grind u to stuff bits into it.

I was referring to the two move protocol in Adam's message (apparently originally by hhanh00 but lost?). not the ordinary commitment there by Sergio.  And I refereed to it as blinding because it makes the numbers in the transcript statistically uniform to a party who doesn't know the secret, and because it's similar in construction to a full blinding scheme-- effectively it's blinding the nonce used by the signer but not the message. Thats all.

Interestingly, the TPM 2.0 signing stuff computes the nonce this way: https://eprint.iacr.org/2013/667.pdf (Section 3), it lets you use a arbitrary point for the nonce multiply.

I wonder if they'd been thinking of s similar blinding scheme?

I don't think the determinism detection is all that interesting.

An evil signer can use the message input as the 'random state' needed to leak data, and be completely deterministic over the inputs.

Take your secret, encrypt it with the attackers pubkey, boost it up with an infinite rate code, use the message to select which codeword of the infinite rate code you're leaking. Thats how I was able to get a 'deterministic' signer that could leak arbitrary sized secrets with enough signatures.

If the concern is the 1 bit failure channel, you can even pre-process the code to make it binary unbalanced so most of the time it's successful, which may make it less obvious that it's using a failure channel to communicate...  (uh, decoders for this may be more complicated however) Though if you don't know the messages that triggered failures, only the successes, your data rate will be very very low unless the failure probability is close to 50%.

Also new wallets created.  And "this time period" is somewhat ambiguous due to caching. For all I know there is some browser tab up someplace running this code that could generate an address and and receive 1000 BTC at any moment.

I can make this non-interactive at a cost of not eliminating the side channel, only drastically reducing it.

This is effectively a scheme  for "sign-to-contract" I was thinking thinking about using for zero-overhead timestamping as a side effect of transactions.

User sends picks a random 256 bit integer t.
Users sends t and the signature request to the signer.

Signer picks a nonce k, computes R = G*k.
Signer computes h=hmac(msg=r,key=t)
Signer computes k' = k+h mod order and R' = R + G*h
Signer signs like normal, using k'
Signer emits signature along with R.

User verifies that R + G*h mod order == signature.r.

This leaves open a side-channel that has exponential cost per additional bit, via grinding the resulting R' mod order.  Using the FEC schemes that I've discussed before it's possible to leak a message of any size using even a single bit channel and enough signatures...  But it eliminates the obvious and very powerful attacks where everything is leaked in a single signature.

This is clearly less good, but it's only a two-move protocol, so many places which wouldn't consider using a countermeasure could pick this up for free just as an element of a protocol spec.

BC.i sometimes uses forced pushes which conceal the prior revisions.

Yep, as everyone says here.. You're misreading the report. Bitcoin is using 1.2GB ram and you have plenty of available memory.

This does a lot less than what most people think it does...


And yet what the poster goes on to describe does not actually accomplish that.  (and, technically, as an aside being first it not really as relevant for copyright, since independent creation is possible and permitted)

Say you invent something.  Now I can go timestamp it.  And claim to have invented it.

Say you invent something and timestamp it.  I can say "I invented it first, he just timestamped a copy of my idea."

We can both timestamp the same thing (or substantially the same thing) and interdependently go show our timestamps to third parties who will never be aware of the other claim.

These ideas are not new... people were commuting to things back in 2010. These ideas reoccur ever couple of months when people don't bother to do any research and see it's all been done before... people just lose interest in it because its limited enough that the value isn't so great.

Worse, most of the reoccurring proposals are highly inefficient (e.g. require a transaction per commitment, when technically no transactions are required _at all_ to get timestamps), or even outright insecure. (Competent folks have mostly given up reviewing ideas from people who don't spend even a moment doing research.)

Combine the amounts. The interface is a dictionary. Your input is not well formed if there is duplication.

Presumably your guideline will recommend users _never_ use uncompressed public keys?

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.