From: Saint Wenhao <saintwenhao@gmail•com>
To: Greg Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: SwiftSync - smarter synchronization with hints
Date: Fri, 2 May 2025 21:15:34 +0200 [thread overview]
Message-ID: <CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ+FuWRA@mail.gmail.com> (raw)
In-Reply-To: <69194329-4ce6-4272-acc5-fd913a7986f3n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 5591 bytes --]
> Is there a faster alternative to sha256?
Hmm, maybe you can avoid hashing at all? If you take txid:vout as it is,
then it will take 36 bytes per output, and you can just treat it in the
same way, as you would some pseudorandom result of some 288-bit hash
function. And then, it is all about mixing the salt with that result.
Of course, then someone could potentially replace "(txid:1) + (txid:4)"
with "(txid:2) + (txid:3)", so maybe it should be replaced with something
else.
And also, there are some types of outputs, where you will know in advance,
how things will be hashed. Which means, that potentially something like
"hashPrevouts" could be used, and then it could make things a little bit
faster, if someone will create a transaction, which will spend some coin,
because some data will be already hashed, and ready to be fetched. But when
I read BIP-143, then it seems, that it could be hard to make such
optimizations (but nonetheless, it could be a good hint, to design future
protocols in a way, which would make such optimizations possible).
pt., 2 maj 2025 o 21:09 Greg Maxwell <gmaxwell@gmail•com> napisał(a):
> On Friday, May 2, 2025 at 11:01:10 AM UTC Ruben Somsen wrote:
>
> I don't see a practical way to do this without compromising the benefits
> of SwiftSync because of the "later find them being spent" part. For one, it
> would require doing a lookup for each input to see if it's in your UTXO
> set, something we currently don't need to do at all. Secondly, it would
> require blocks to be processed in order, limiting parallelization. The
> space savings would also be negligible, considering the hint data is
> already <100MB (compressed).
>
>
> Doh. Right. Got too excited.
>
>
> I think most of the remaining optimization potential (other than the
> engineering work to enable parallel validation) is in the hash
> aggregate, like the midstate reuse. Is there a faster alternative to
> sha256? Can we get away with 16 byte hashes? I could be mistaken, but in
> theory it seems we could even get away with 4 byte hashes if we allowed for
> a 1 in 4 billion chance of accidentally accepting an invalid chain. Leaving
> consensus to chance feels philosophically improper, but it's a pretty safe
> bet considering it also involves PoW to trigger and even then would only
> affect one or two random unlucky people on Earth.
>
>
> I think the problem isn't so much the size of the hash output, but rather
> the property you need is that each salt gives you a different hash function
> such that the attacker cannot predictably create collisions. The most
> expedient way to get there is a cryptographic hash function, which limits
> you lower performance choices. Your reduction function could just be xor
> and if it is I doubt the output size itself matters much for performance...
> and my guess is that e.g. xor with 32 byte hashes will have better
> performance than addition with 16 bytes.
>
> It doesn't need to be so in the initial implementation but ultimately it
> may make sense for the host to benchmark available hashes and pick the
> fastest. SHA-256 will easily be a winner on hardware with SHA-NI or
> similar. But there are other cryptographic hashes in the codebase that
> might be faster on systems without sha256 hardware support.
>
> There are argument I can see to prove the security of simpler hashes that
> only work if you assume that the attacker could only insert specific finite
> numbers of bad changes... but they really have completely full control of
> the hash function input except for the salt and that I think makes it hard
> to say much positive about the security of any optimization except
> truncating a secure hash (and I don't think truncating will win you much
> security).
>
> In terms of security keep in mind that a prospective attacker needs to
> also perform POW to get their attack chain up to the users accepted chain
> tip, which means that they have to do the work between the AV point and the
> tip assuming the user isn't isolated. This fact could be used to justify a
> rather weak hash function, but I think it's not really worth a lot of
> analysis ahead of the initial functionality. I'm guessing that once this
> is implemented, even if its with a quite expensive hash function that the
> IBD performance will be heavily bottlenecked in network and parallelism
> related issues and be far from the lowest hanging fruit for a while,
> considering that this has eliminated the big sequential part and a number
> of annoying to optimize components entirely.
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/69194329-4ce6-4272-acc5-fd913a7986f3n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/69194329-4ce6-4272-acc5-fd913a7986f3n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ%2BFuWRA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6768 bytes --]
next prev parent reply other threads:[~2025-05-03 11:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-09 10:10 [bitcoindev] " Ruben Somsen
2025-05-02 6:47 ` [bitcoindev] " Greg Maxwell
2025-05-02 10:59 ` Ruben Somsen
2025-05-02 13:38 ` Saint Wenhao
2025-05-02 16:07 ` Greg Maxwell
2025-05-02 19:15 ` Saint Wenhao [this message]
2025-05-02 20:23 ` Sanket Kanjalkar
2025-05-03 12:02 ` Greg Maxwell
2025-05-03 13:42 ` Ruben Somsen
2025-05-03 13:57 ` Greg Maxwell
2025-05-03 14:36 ` Greg Maxwell
2025-05-03 14:55 ` Ruben Somsen
2025-05-03 15:54 ` Greg Maxwell
2025-05-03 16:24 ` Ruben Somsen
2025-05-03 13:53 ` Weikeng Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ+FuWRA@mail.gmail.com \
--to=saintwenhao@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox