<unnamed>

Public Key

npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5

Profile Code

nprofile1qqstcj6u8smx7dhe8237yc04c7pjaju9zd6n0wh4arcq5sepap0sgacpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsyx0qkd

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:53:34 UTC

- reply

📅 Original date posted:2016-09-23
📝 Original message:On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> scripting system to address reissuing bitcoin transactions when the coins
> they spend have been conflicted/double-spent.
>
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
Can you walk us through a real live usecase which this solves? I read it and
I think I understand it, but I can't see the attack every giving the attacker
any benefit (or the attacked losing anything).

2023-06-07 17:50:20 UTC

- 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 17:50:19 UTC

- 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.