Zooko Wilcox-OHearn [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-05-25 to 2015-12-17
💬 Posted a total of 6 messages
📚 Participated in the following categories: Bitcoin-development, softfork proposal, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:45:27

- reply

📅 Original date posted:2015-12-17
📝 Original message:
On Thu, Dec 17, 2015 at 6:08 PM, Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
>
> Currently, in our code, node ID's take two forms: either the hash160
> (Bitcoin style) of a node's current pub-key or the raw serialized pub-key
> itself. This is done such that "nodeID at host" locators explicitly provide a
> level of backwards (p2pkh) compatibility for end wallets that are unable to
> establish a connection in a timely manner.
I'm afraid I don't understand how this backwards-compatibility works,
so if it is important that I understand it please point me to docs or
explain it more.
> Within the Sphinx mix-header, I think we should be safely able to truncate
> this (the hash160) to 16-bytes. In the case of a collision, the onion-route
> propagation across the incorrect node will simply fail, as it won't be able
> to properly derive the shared secret.
Do you mind explaining why you think this is safe? I don't understand
how it could be safe, in the case that the attacker knows a private
key that maps to the same 128-bit nodeid as a user's private key does.
> Otherwise, we'd be forced to ditch chacha20+poly3015 for
> AES-CTR+SHA-256-HMAC within Sphinx if serialized pub-keys are used for node
> ID's in the routing info.
I don't understand why the use of entire public keys instead of
possibly-truncated hashes of public keys would force a decision about
which cipher and MAC to use.
Sincerely,
Zooko

2023-06-09 12:45:26

- reply

📅 Original date posted:2015-12-16
📝 Original message:
I'm so happy to see this direction of re-using prior work — SPHINX —
instead of inventing a new wheel. Thank you, roasbeef!
On Tue, Dec 15, 2015 at 11:38 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> I'm happy to the crypto experts debate AES-CTR + HMAC-SHA-256 (which I used) vs ChaCha20+poly1035.
I'd prefer ChaCha20+poly1305.
> 128 bits definitely seems a bit tight for node ids: I assumed a full
> bitcoin EC pubkey in my current implementation.
I have a pretty good sense of how risky short node ids are, but I
don't have a good idea of how costly long node ids are in this
context. I also don't know how many node ids are likely to exist in
the long-run, successful scenario. 10⁹? 10¹²? Not more than 10¹⁵!
I'd suggest 192-bit nodeids, based on such musings as:
* http://ecrypt-eu.blogspot.de/2015/11/break-dozen-secret-keys-get-million.html
* http://www.keylength.com/en/compare/
I feel confident that 192-bit nodeids are safe enough. Whether they
are, practically speaking, more efficient than 256-bit nodeids I'll
leave up to you to answer.
> Matts was really interested in sending messages over LN, though, so no
> doubt he'll be salivating at the idea of extending in this direction :)
☺
> Sure, let's discuss that. I want to modify the handshake anyway to
> include a <len> prefix (like every other message). This lets us upgrade
> the crypto later, by appending a key for a different system.
>
>> 1. https://tools.ietf.org/html/rfc7539 (Section 4)
>
> That's a definite MUST READ for any implementer...
+1! Please don't assume that your endpoint can reliably update
persistent state, and if at all possible don't assume that your
platform's CSPRNG is good. This is the weakest point in the system
IMHO, based on empirical evidence.
A good way to strengthen this weak point is to mix persistent state,
*and* platform CSPRNG, *and* mix in unique and/or private information
from the current protocol state, so that if any of those one is good
then your nonce is unique and your key unguessable.
> PS. Are we having fun yet?
YES!
Regards,
Zooko

2023-06-09 12:44:26

- reply

📅 Original date posted:2015-09-21
📝 Original message:
Could you please point me to any notes about requirements/desiderata?
Thanks!
--Zooko
On Sep 18, 2015 5:47 PM, "Rusty Russell" <rusty at rustcorp.com.au> wrote:
> Hi all!
>
> So, we've handwaved that we're going to have onion routing, so
> each node can only see the immediate neighbors.
>
> Here's my first attempt; please fix :)
>
> The format of a route looks like so:
>
> required bytes route;
>
> A node decrypts that using its pubkey (probably some counter mode
> scheme, but that's for a different post!), expecting:
>
> // Sum of this whole thing after decryption.
> required sha256_hash sum = 1;
>
> // Where to next?
> oneof next {
> // Actually, this is the last one
> bool end = 2;
> // Next lightning node.
> pubkey lightning = 3;
> // Other realms go here...
> }
>
> // How much fee you can take (== all, if last node)
> required int32 fee = 4;
>
> // Remainder (route blob for next node).
> required bytes route = 5;
>
> If the sum is wrong, the routing has failed (it's been corrupted or was
> malformed to start).
>
> Nodes create the route backwards, to calculate the size. Then picks a
> total size randomly between 1024 and 4096, and pads to that size (at
> least 32 bytes of random padding). Then walks backwards to wrap and
> encrypt it.
>
> This offers some protection from guessing the route length.
>
> Route Probing Attacks
> =====================
> Now, there's a weakness here: No MAC! A nosy node can't corrupt the
> routing past the next hop, but it could replace it entirely (this is
> fundamental to the scheme of R values). If it guesses the final
> destination right, the HTLC will succeed, otherwise it will fail, so it
> can use this to probe.
>
> One partial defence is to fail to allow two HTLCs with the same R value,
> forcing probe serialization. Unfortunately that allows a simple way to
> probe back to the source, so we shouldn't do this!
>
> We may be able to do some probabalistic backoff of duplicate R values,
> such that you can't tell if I've received one before? A more
> sophisticated probe sequence could get a probability though...
>
> I can't see a fix for this in general. :(
>
> Error Messages
> ==============
> Another issue is that we should try not to leak information to passive
> observers on the route due to errors, so signing errors and using the
> 'sum' field as a secret key seems sensible. This means your padding in
> the original message needs to be "random" so 'sum' is random.
>
> Thoughts welcome!
> Rusty.
> PS. As noted before, nodes can trivially correlate HTLCs by R value, so
> onioning the routing only gets you so far...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150922/1abdd47c/attachment-0001.html>

2023-06-07 15:32:09

- reply

📅 Original date posted:2015-03-19
📝 Original message:I'm in favor of relative CHECKLOCKTIMEVERIFY, but I don't have a very
specific reason. I just have a vague worry that there can be "race
conditions" in which a txn with an absolute CHECKLOCKTIMEVERIFY goes
into the blockchain later than one of its signers expected that it
would, and therefore there is a surprisingly short delay between that
transaction going into the blockchain and becoming spendable.
This worry of mine is assuaged by using relative CHECKLOCKTIMEVERIFY instead.
Regards,
Zooko

2023-06-07 15:28:57

- reply

📅 Original date posted:2015-01-22
📝 Original message:.Hi there. Thank you for your work on this.
I've looked over https://gist.github.com/sipa/5d12c343746dad376c80 and
https://github.com/sipa/bitcoin/commit/bipstrictder . I didn't
actually audit the included reference implementation of
IsValidSignatureEncoding(), and I didn't check whether the test
vectors in https://github.com/sipa/bitcoin/commit/f94e806f8bfa007a3de4b45fa3c9860f2747e427
exercise all of the branches that are changed by this patch.
I have the following comments:
* It seems like a good idea to do this.
* I don't see any problem with using the upgrade mechanism from BIP 34
for this. It's cool! I'm happy that such a mechanism seems to work in
practice.
* Should the bipstrictder give a rationale or link to why accept the
0-length sig as correctly-encoded-but-invalid? I guess the rationale
is an efficiency issue as described in the log entry for
https://github.com/sipa/bitcoin/commit/041f1e3597812c250ebedbd8f4ef1565591d2c34
.
* Does this mean there are still multiple ways to encode a correctly
encoded but invalid signature, one of which is the 0-length string?
Would it make sense for this change to also treat any *other*
correctly-encoded-but-invalid sig (besides the 0-length string) as
incorrectly-encoded? Did I just step in some BIP62?
* It would be good to verify that all the branches of the new
IsDERSignature() from
https://github.com/sipa/bitcoin/commit/0c427135151a6bed657438ffb2e670be84eb3642
are tested by the test vectors in
https://github.com/sipa/bitcoin/commit/f94e806f8bfa007a3de4b45fa3c9860f2747e427
. Eyeballing it, there are about 20 branches touched by the patch, and
about 24 new test vectors.
* It would be good to finish the TODOs in
https://github.com/sipa/bitcoin/commit/b7986119a5d41337fea1e83804ed6223438158ec
so that it was actually testing the upgrade behavior.
* missing comment:
https://github.com/sipa/bitcoin/commit/e186f6a80161f9fa45fbced82ab1d22f081b942c#commitcomment-9406643
Okay, that's all I've got. Hope it helps! Thanks again for your good work!
Regards,
Zooko

2023-06-07 15:02:26

- reply

📅 Original date posted:2013-05-25
📝 Original message:jgarzik wrote:
> 1) Rule changes. We don't want these.
In general? What constitutes a rule change?
For example, if I understand correctly (from what Gavin said at
Bitcoin 2013), there is a move afoot to lift the block size limit.
Although, when I went to confirm my understanding by reading the
bitcoin-development list archives, I don't see mention of this. Is
there another forum I should be reading if I want to follow Bitcoin
development?
Anyway, I hope that there are some rule changes that you would
consider for Bitcoin, although I recognize there are vast classes of
such changes that you wouldn't.
I'm trying to figure out what's the most productive way to show you,
and everyone, candidates for such changes. Things that are definitely
not suitable for merging to trunk tomorrow, but might be suitable in a
year or two, or "Next Time We Have A Hardfork".
I don't think alternative bitcoin-clones are the best venue for those.
Although they are certainly good venues for changes which can never
make it into Bitcoin.
Perhaps the best venue for such a thing is just to fork bitcoin.git on github.
Regards,
Zooko Wilcox-O'Hearn
Founder, CEO, and Customer Support Rep
https://LeastAuthority.com