Delivery-date: Sun, 04 May 2025 02:12:10 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::52a as permitted sender) client-ip=2607:f8b0:4864:20::52a;
MIME-Version: 1.0
References: <CAPv7TjaM0tfbcBTRa0_713Bk6Y9jr+ShOC1KZi2V3V2zooTXyg@mail.gmail.com>
 <cc2dfa79-89f0-4170-9725-894ea189a0e2n@googlegroups.com> <CAPv7TjaDGr4HCdQ0rR6_ma5zh2umU9r3_529szdswn_GjjnuCw@mail.gmail.com>
 <69194329-4ce6-4272-acc5-fd913a7986f3n@googlegroups.com> <CAExE9c8XfEH__onX3DhUQh0OnvpoOLwRRp8+Z6PozyKGtqpspw@mail.gmail.com>
 <fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n@googlegroups.com>
In-Reply-To: <fbf06c5b-57b6-4615-99bb-3a7ea31ebf22n@googlegroups.com>
From: Nagaev Boris <bnagaev@gmail.com>
Date: Sat, 3 May 2025 22:06:38 -0300
Message-ID: <CAFC_Vt6BgUFt5+zbSKzHyN4Sk1nFw5hbXVcv_jdUzA5RJvwFBg@mail.gmail.com>
Subject: Re: [bitcoindev] Re: SwiftSync - smarter synchronization with hints
To: Greg Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

On Sat, May 3, 2025 at 9:07=E2=80=AFAM Greg Maxwell <gmaxwell@gmail.com> wr=
ote:
>
> On Saturday, May 3, 2025 at 11:55:28=E2=80=AFAM UTC Sanket Kanjalkar wrot=
e:
>
> > hash(UTXO_A||salt) + hash(UTXO_B||salt) - hash(UTXO_C||salt) - hash(UTX=
O_D||salt) =3D=3D 0 (proving (A=3D=3DC && B=3D=3DD) || (A=3D=3DD && B=3D=3D=
C))
>
> What if instead of hash we encrypt with AES and modular add/subs? I canno=
t 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) =3D=3D 0 =3D>  (proving (A=3D=3DC && B=3D=3DD) || (A=3D=3DD && B=3D=
=3DC))?
>
>
> AES in CTR mode is, I'm not sure about other modes? Obviously CTR mode wo=
uld be unsuitable! (I mean sure modular add/sub and xor are different opera=
tions 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 iss=
ue.

Can Haraka V2 [1] hash function be used? It is based on AES and
supports 256 or 512 bit inputs. UTXO (txid + index) has a fixed size
and fits into 320 bits. We can use the 512 bit version and just leave
the remaining bytes zero.

[1] https://github.com/kste/haraka

--=20
Best regards,
Boris Nagaev

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAFC_Vt6BgUFt5%2BzbSKzHyN4Sk1nFw5hbXVcv_jdUzA5RJvwFBg%40mail.gmail.com.