&gt; I already told you, when I said "known plaintext attack". If you want to put random data into private keys or signatures, then things are hard to break. However, if it is something useful for the reader, then usually, that kind of data are non-random. For example: some users store transactions inside OP_RETURNs, and they use ASCII hex representation. If they would use binary encoding, then they would save 50% space. But people simply don't care.<br /><br />&gt; And the similar case is possible here: if you want to store random data, then it is hard to use this method. However, if you want to store ASCII text, where many words can be found in a dictionary, or where the format of the data is known upfront, or can be easily guessed, then the security of the keys, is comparable to the brainwallets.<br /><br />&gt; Which means, that you can just put your data into the private key of the user, and a "signature nonce" (which is nothing else, but yet another private key, placed on secp256k1). And then, if you know, that your data, is for example "ASCII string", then it means, that each and every key, that you produce, simply leaks at least 32 bits per 256-bit key, if not more.<div><br /></div><div>Ah, right; I had originally written a response to this idea but then discarded it on the basis that it's kinda "obvious" that we shouldn't think about that, and focused on the more in-the-weeds concept of a lattice attack instead.</div><div><br /></div><div>But it isn't obvious.</div><div><br /></div><div>So let's think of the spectrum here. First, the most trivial nonce to break: one consisting of a single bit (OK technically you can't encode k=0, heh, but, whatever, put it in the second bit of the string). Obviously that is extractable, getting 32 bytes plus one bit. That one extra bit above the 33% is achievable because of "grinding" except here grinding is the most trivial version possible: trying 2 alternatives. This still fits my original claim, which is "33% plus whatever you can get from grinding, and you leak the secret key in the process".</div><div><br /></div><div>Other end of the spectrum: not 1 bit or 5 bytes but say 20 bytes represent an actual message, and let's say the rest of the 256 bit k-string is zero. Now clearly one can't grind that, if it's random. Which brings us to your point about weakness: let's say the 20 bytes of message comes from a space of possible messages, known to all potential readers, whose size is actually 40 bits. Because they can grind 40 bits, they can retrieve the message, but that message is only 40 bits of information. E.g. most crude idea; a table of 2^40 messages, you are picking one .. notice it doesn't matter if the length of each message is 40 bits or 160 bits or 256 bits; you are only conveying 40 bits of *information* if you do this.</div><div><br /></div><div>From this point of view it's pretty clear that we haven't changed the general conclusion: you only get 33% (say 32 bytes), *plus* whatever you can get from grinding, and since that's exponential work, it's never going to be very big, say 5 bytes or possibly 6? And you leak the key of course.</div><div><br /></div><div>I do agree with you that there could be scenarios where this "mode" of publication/embedding might be the preferable one, because we're gliding over that line between "pure publication" and "publication with sidechannels". As I argued here and elsewhere, if there is a proper, viable, sidechannel, then most of this analysis doesn't apply but a sort of mixup where "if you know information X you can grind out more information Y from the onchain data" is possible.</div><div><br /></div><div>But no, as per the above, you are definitely not conveying 66% (that is to say , 64 bytes out of 96) in the P, R, s tuple using this method. That'd only be true in the sense that if the space of possible messages is "hello world\n\n" and "goodbye world" and then you claimed you were sending 13 bytes because a reader can find the message.</div><div><br /></div><div>Cheers,<br />AdamISZ/waxwing<br /><br /></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/31d18bd9-62e0-4035-b04f-f70ff4253257n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/31d18bd9-62e0-4035-b04f-f70ff4253257n%40googlegroups.com</a>.<br />