From: Ruben Somsen <rsomsen@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Greg Maxwell <gmaxwell@gmail•com>,
saintwenhao@gmail•com, Sanket Kanjalkar <sanket1729@gmail•com>
Subject: Re: [bitcoindev] Re: SwiftSync - smarter synchronization with hints
Date: Sat, 3 May 2025 15:42:39 +0200 [thread overview]
Message-ID: <CAPv7TjYCaAsJFo3t6A6HmoojnbMNjSRkXHeOW=jrbGBpPYzQVg@mail.gmail.com> (raw)
In-Reply-To: <fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]
Hey all,
@Saint Wenhao
>if you take the sum of hashes, which should be finally zero, then by
grinding UTXOs, someone could make it zero
That's what the secret salt prevents. You can't grind for a certain number
if you don't know what the number is you are trying to collide with.
>maybe you can avoid hashing at all [...] And then, it is all about mixing
the salt
Without a concrete solution I'm afraid that's wishful thinking. That last
part of the sentence is why we currently need the hash, as well as for
adding more data in the non-assumevalid version.
@Sanket Kanjalkar
>What if instead of hash we encrypt with AES
I can't really evaluate whether this might work, but I can see the line of
reasoning. Conceptually, I think what we need is something that transforms
the data into fixed length blocks for which an attacker can't know the
relationship between each block (i.e. via a secret). The transformation
needs to be the same on the input and output side.
@Greg Maxwell
>Your reduction function could just be xor
I had initially ruled XOR out. Reason for this is that XOR would lead one
to conclude that sets [A, B, C, C], [A, B], [A, B, D, D], etc. are all
equivalent because any two values cancel each other out, regardless of
whether the sets are on the input or output side. Modular add/sub doesn't
have this issue. If the speedup actually turns out to be significant then
there may be some clever way to salvage it like by counting the total
number of inputs and outputs and relying on the knowledge that every txid
must be unique, but that's a lot harder to reason about.
>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
Very true, and as you said, we can easily drop-in replace the hash function
at any future point we like, without adverse consequences.
Cheers,
Ruben
On Sat, May 3, 2025 at 2:07 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> On Saturday, May 3, 2025 at 11:55:28 AM UTC Sanket Kanjalkar wrote:
>
> > hash(UTXO_A||salt) + hash(UTXO_B||salt) - hash(UTXO_C||salt) -
> hash(UTXO_D||salt) == 0 (proving (A==C && B==D) || (A==D && B==C))
>
> What if instead of hash we encrypt with AES and modular add/subs? I cannot
> prove it; but I also don't see a clear way this is broken.
>
> 1. Sample random symmetric key `k`
> 2. Instead of above; AES_k(UTXO_A) + AES_k(UTXO_B) - AES_k(UTXO_C) -
> AES(UTXO_D) == 0 => (proving (A==C && B==D) || (A==D && B==C))?
>
>
> AES in CTR mode is, I'm not sure about other modes? Obviously CTR mode
> would be unsuitable! (I mean sure modular add/sub and xor are different
> operations but they are quite close). I think that in many modes the
> collision resistance would have to at least be restricted by the birthday
> bound with the small block size. I think CMC might be needed to avoid that
> sort of issue.
>
>
>
> --
> 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/fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n%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/CAPv7TjYCaAsJFo3t6A6HmoojnbMNjSRkXHeOW%3DjrbGBpPYzQVg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5644 bytes --]
next prev parent reply other threads:[~2025-05-03 13:47 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
2025-05-02 20:23 ` Sanket Kanjalkar
2025-05-03 12:02 ` Greg Maxwell
2025-05-03 13:42 ` Ruben Somsen [this message]
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='CAPv7TjYCaAsJFo3t6A6HmoojnbMNjSRkXHeOW=jrbGBpPYzQVg@mail.gmail.com' \
--to=rsomsen@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)com \
--cc=saintwenhao@gmail$(echo .)com \
--cc=sanket1729@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