<unnamed>

Public Key

npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5

Profile Code

nprofile1qqstcj6u8smx7dhe8237yc04c7pjaju9zd6n0wh4arcq5sepap0sgacprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqmvxylr

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:50:20 CEST

- reply

📅 Original date posted:2016-05-09
📝 Original message:On Monday 09 May 2016 13:40:55 Peter Todd wrote:
> >> [It's a little disconcerting that you appear to be maintaining a fork
> >> and are unaware of this.]
> >
> >ehm...
>
> Can you please explain why you moved the above part of gmaxwell's reply to
> here,
A personal attack had no place in the technical discussion, I moved it out.
Initially I asked him to please avoid personal attacks, but I thought better
of it and edited my reply to just "ehm...".
The moderators failed to catch his aggressive tone while moderating my post
(see archives) for being too aggressive.
I'm sure this message will also not be allowed through. I would not even blame
the moderators since this, and Peters, messages were both off-topic.
I thank you for todays talks, it makes me certain of the thing I said this
weekend on Reddit that this list is not a suitable place for all the different
stakeholders to talk on a level playing field.
If any of you agree, please urge the approach that we replace the entire
moderation team with a new one. This will be the least painful solution for
everyone in the ecosystem.
Thanks again.

2023-06-07 19:50:19 CEST

- reply

📅 Original date posted:2016-05-09
📝 Original message:On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote:
> On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
>
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > You misunderstand the networking effects.
> > The fact that your node is required to choose which one to set the
> > announce
> > bit on implies that it needs to predict which node will have the best data
> > in the future.
>
> Not required. It may.
It is required, in the reference of wanting to actually use compact block
relay.
> Testing on actual nodes in the actual network (not a "lab") shows
Apologies, I thought that the term was wider known. "Laboratory situations"
is used where I am from as the opposite of real-world messy and unpredictable
situations.
So, your measurements may be true, but are not useful to decide how well it
behaves under less optimal situations. aka "the real world".
> This also _increases_ robustness. Right now a single peer failing at
> the wrong time will delay blocks with a long time out.
If your peers that were supposed to send you a compact block fail, then you'll
end up in exactly that same situation again. Only with various timeouts in
between before you get your block making it a magnitude slower.
In networking this is solved by reacting instead of predicting. The network is
not stable. Your protocol design assumes it to be.
> > Another problem with your solution is that nodes send a much larger amount
> > of unsolicited data to peers in the form of the thin-block compared to
> > the normal inv or header-first data.
>
> "High bandwidth" mode
Another place where I may have explained better.
This is not about the difference about the two modes of your design.
This is about the design as a whole. As compared to current.
> > Am I to understand that you choose the solution based on the fact that
> > service bits are too expensive to extend? (if not, please respond to my
> > previous question actually answering the suggestion)
> >
> > That sounds like a rather bad way of doing design. Maybe you can add a
> > second service bits field of message instead and then do the compact
> > blocks correctly.
> Service bits are not generally a good mechanism for negating optional
> peer-local parameters.
Service bits are exactly the right solution to indicate additional p2p
feature-support.
> [It's a little disconcerting that you appear to be maintaining a fork
> and are unaware of this.]
ehm...
> > Wait, you didn't steal the variable length encoding from an existing
> > standard and you programmed a new one?
>
> This is one of the two variable length encodings used for years in
> Bitcoin Core. This is just the first time it's shown up in a BIP.
>
> > Look at UTF-8 on wikipedia, you may have "invented" the same encoding that
> > IBM published in 1992.
>
> The similarity with UTF-8 is that both are variable length and some
> control information is in the high bits. The similarity ends there.
That's all fine and well, it doesn't at any point take away from my point that
any specification should NOT invent something new that has for decades had a
great specification already.
If you make a spec to be used by all nodes, on the wire, don't base it on your
proprietary implementation. Please.
> > Just the first (highest) 8 bytes of a sha256 hash.
> >
> > The amount of collisions will not be less if you start xoring the rest.
> > The whole reason for doing this extra work is also irrelevant as a spam
> > protection.
>
> Then you expose it to a trivial collision attack: To find two 64 bit
> hashes that collide I need perform only roughly 2^32 computation. Then
> I can send them to the network.
No, you still need to have done a POW.
Next to that, your scheme is 2^32 computations *and* some XORs. The XORs are
percentage wise a rounding error on the total time. So your argument also
destroys your own addition.
> This issue is eliminated by salting the hash.
The issue is better eliminated by not allowing nodes to send uninvited large
messages.
I don't think we're getting anywhere.
I'm not sold on your design and I explained why. I tried explaining in this
email some misconceptions that may have appeared after my initial emails. I
hope things are more clear.

2023-06-07 19:49:57 CEST

- reply

📅 Original date posted:2016-03-25
📝 Original message:On Wednesday 23 Mar 2016 22:55:34 Jonas Schnelli via bitcoin-dev wrote:
> >> I have just PRed a draft version of two BIPs I recently wrote.
> > * why would you not allow encryption on non-pre-approved connections?
>
> The encryption should be optional.
> The proposed authentication scheme does take care of the
> identity-management and therefor prevent MITM attacks.
> Without the identity management, you might not detect sending/receiving
> encrypted data from/to a MITM.
If you want to extend the Bitcoin protocol itself, you will have to resolve
that. Which many other solutions do (ssh for instance).
It would not be Ok to have an peer-to-peer encryption system that doesn't
allow non-pre-approved connections.
> > * What is the reason for using the p2p code to connect a wallet to a node?
> > I suggest using one of the other connection methods to connect to the
> > node.
> > This avoids a change in the bitcoin protocol for a very specific usecase.
>
> Most known use-case: SPV.
You didn't answer the question.
> > * Why do you want to do a per-message encryption (wrapping the original)?
> > Smaller messages that contain predictable content and are able to be
> > matched to the unencrypted versions on the wire send to other nodes will
> > open this scheme up to various old statistical attacks.
>
> It's probably extremely inefficient to create a constant time stream.
Your use of "probably" makes me wonder if you already have an implementation.
Doing any encryption and handshaking design *without* actually having it coded
and gone though testing yet makes no sense.
I do not belief Bitcoin will benefit from "design by committee" where a
specification is drawn before an implementation is written.
Also, you didn't actually address the attack-vector.
> >> Responding peers must ignore (banning would lead to fingerprinting) the
> >
> > requesting peer after 5 unsuccessfully authentication tries to avoid
> > resource attacks.
> >
> > Any implementation of that kind would itself again be open to resource
> > attacks.
> > Why 5? Do you want to allow a node to make a typo?
>
> Good point. Maybe one false try should lead to ignoring the peer.
That doesn't take away the resource attack at all.
> >> To ensure that no message was dropped or blocked, the complete
> >> communication>
> > must be hashed (sha256). Both peers keep the SHA256 context of the
> > encryption session. The complete <code>enc</code> message (leaving out
> > the hash itself) must be added to the hash-context by both parties.
> > Before sending a <code>enc</code> command, the sha256 context will be
> > copied and finalized.
> >
> > You write "the complete communication must be hashed" and every message
> > has a hash of the state until it is at that point.
> > I think you need to explain how that works specifically.
>
> This is a relative simple concept and does not require rehashing the
> whole communication.
Apologies, I should have been more clear; the BIP should specify the actual
algorithm, otherwise you can't create an implementation from just reading the
BIP.
Also, this may be a good time to ask why you want to have a per-message
encryption?
Practically every single popular end-to-end encryption uses one approach or
another were it just encrypts as another layer. (the L in ssl). You are
mixing layers, and unless you do that for a very good reason, or have a very
good reason why everyone else is doing it wrong, I suggest using a layered
encryption approach.