path: root/c0/16570875cc27ca1e9818a33d21de4313795f1c

Delivery-date: Sat, 03 May 2025 04:55:36 -0700
Received: from mail-qt1-f184.google.com ([209.85.160.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC7YL44NVYFRBLEI3DAAMGQE2EHBHOQ@googlegroups.com>)
	id 1uBBSw-0007Xw-NZ
	for bitcoindev@gnusha.org; Sat, 03 May 2025 04:55:36 -0700
Received: by mail-qt1-f184.google.com with SMTP id d75a77b69052e-47689dc0f6dsf53857151cf.3
        for <bitcoindev@gnusha.org>; Sat, 03 May 2025 04:55:34 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1746273328; cv=pass;
        d=google.com; s=arc-20240605;
        b=P8wLrNB+Fq3z5FC5RdZqR6c0Tp7lblzeMC6es+GmOYWHk4740ikOkZolXxZEcB6ZXF
         mlm1wN5M5/uKUnU6LIQi2uBoV0H37OPT6tLa0itm8mUsA0RZRLEijoPkUOdWZx38B8oI
         BJlZpkYFKR1H0rcCiyDPAi10CYBuvUl9A0b3eA4tlUVuElcke8urwIUZzwDlyLc68GcJ
         BEvTLqd/shqlx/okJEm9dG/hTHQ+seS2dM2PVmTY0aEZi7TmWR3UsVJIK9FlrHKiRefF
         LlDYTpOv7PxAHZNiXnhG8Or+tJadHb5VIaM/7O6GsotiGyS5L05gyCluuuKjh10baM/H
         MWQA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=Nw9GNaGftTa/hSZJaMajNyVYBG4ZIOzH/5vsEHGKaAU=;
        fh=Ohdull/r1R269jp/ZvHhA42iTKWztbraC8ox9eqv0F8=;
        b=LKwo0NERrc7jvIiRnMTocM4dC4GBq73h0HM3+mSrGM3/CYcgYsEDZJqe8Bnswms9OK
         pXcPwJOn154J/hYfmZAXvLBRVj2HK9F/VeJ1GIo3nvJ2lz6tSROlE4jr649sAdvhvCFn
         NZ/vb78O6N0kYO0zUtOAyDXfBNXimQp5Hg7Dz4xTGXQ6ARwtezSZ4FnWqA3UJazAVCVO
         CbPAUToXXROf3kuY7lVirYHVlmF3k6JoIRnw60Ns5rOa3NKxXzRtZYqpP0KaQ6Bn/SRl
         s+hei0SuTgphSRZKjScStPCUPWhNq0wjuRVMr2Idijy0GEI+AbWEZg08RY/fVwGR5QIk
         pyYw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=b6b1+FAw;
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746273328; x=1746878128; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Nw9GNaGftTa/hSZJaMajNyVYBG4ZIOzH/5vsEHGKaAU=;
        b=qwi1X+j8VHzi1kLaBTBncgptOmRCKIZL2P2cHVYclXOgOxMizTVXGeTk3LLxC1RGuj
         k7l3rBliTvFuQdtqQ87y+31OYLk0jRCCQLMFfChFVXMKeYX7DH+/vV09Hg4C7LbcvT5D
         /zqhl88GUskDZAeWJOz2Xb4gZy95LQAqKnaDbOsv/InQ4AqeSqsJzX+dkEYoyr4HBqBQ
         UIUG65BmWwVkz/IeyTZERe9RxE2LcbizrUqDvNU88SgGFO4nwVEbJ93KdxpYDN2YVOXU
         BAwqSmVQME8Jykg3c/CTqANrXljNIwmQUqdSXdW9TnkyAnARyoidHhlWvUEGQxIGgpzi
         kINg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746273328; x=1746878128; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Nw9GNaGftTa/hSZJaMajNyVYBG4ZIOzH/5vsEHGKaAU=;
        b=iOOWo3x/2PdBiA6Rz2tbqsZPV+jRUICHPtoR6h8cgyZu3OvGE3kujNEl/uKU2DnHFZ
         d0Ih0yD4VdE49qFbVKnHjWy2xo3s/dCenZrdDBRGZ8lPCBK1YLSnPg3/rW51SXWaXWw4
         Iixg93zkZTAQNKPAuNITUwccnheb53/THliy7UGOX9Y3GtUTWm+fUjI7TfzxAh+WcEh+
         V+XlVQimKsKOJz3H6hxlmfRO0x021SYchOnargCvv1nG7YRK5TUmWHbGU9mvSmdi8miN
         vFt+NsfqRHUSfhSPEBd9DOzYNLarN75sQn99yR8igAIcPrxd6LKe/LPPMdWH0w00Qqe2
         +P9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746273328; x=1746878128;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=Nw9GNaGftTa/hSZJaMajNyVYBG4ZIOzH/5vsEHGKaAU=;
        b=HPaQEh2vRQbdzjzmj98RP/+OUauv0HdWgCRW2GAiA8dmmHXLF5o6HzPeRyFRJQUQ3i
         +R5TsXp36WG43zIUzbu5CNb0kVMDOtbQA5LO8AUzUHgk8PvsW4lRzpZ/J9WX/hn69z9I
         XxpoO4zHTdNxhjVtqxihF0v50TXc6DiANzM7/06NFY4FZ42Y41wxRf7kmv8JKnOAxhkW
         yfX6+j2VLD/H3shFX9ZsIk1RE1FV/WjxCNYwGDYwaQAKJ218xPr8l7OvtJAguLEAJgg0
         CTLT8A3BFAbbhwTI3Rlb7S2H/U9RbnoBYeCsN30FsVO9tlUgdKC9Gi31O+3WmxlrmNv8
         ptZw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXOGA5/8tw0PS7neKuwOBLf9ABF85xMBHRrslEhJtsbNwVj7hS7F7zcQI3j7/7P9Keoleop8C0+0gww@gnusha.org
X-Gm-Message-State: AOJu0YylepsfVgbcl9PyXn74D4NA+vUppRpjVxLl0M6HR1mcegUdmqNW
	wnFaXhUa4g8rvF0JU84RTdurA25z9QroIlRMmTFSU5LNiPT3Yo1r
X-Google-Smtp-Source: AGHT+IGsz89Y+uJqe8ZiswtKARxYFBrRRBLZODGaZk5sanv0QMSRvQQlNcPZFvK5PFi2xJsACB3P5A==
X-Received: by 2002:a05:622a:11c8:b0:476:9b34:fe82 with SMTP id d75a77b69052e-48dffdc5aa7mr10215861cf.31.1746273328215;
        Sat, 03 May 2025 04:55:28 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEyvGwpiA98HQcYc4kugoiVgU+B+Y4Qg9nhNRKA9c0tiw==
Received: by 2002:a05:622a:a038:b0:476:7bf7:255e with SMTP id
 d75a77b69052e-48ad89a0f98ls32376471cf.1.-pod-prod-05-us; Sat, 03 May 2025
 04:55:24 -0700 (PDT)
X-Received: by 2002:a05:620a:1aa7:b0:7c5:50ab:ddf7 with SMTP id af79cd13be357-7cae3b0a8e6mr92783685a.52.1746273324148;
        Sat, 03 May 2025 04:55:24 -0700 (PDT)
Received: by 2002:a05:6504:1084:b0:293:32b4:31b9 with SMTP id a1c4a302cd1d6-2acb75afcb0msc7a;
        Fri, 2 May 2025 12:15:48 -0700 (PDT)
X-Received: by 2002:a2e:b894:0:b0:30c:4610:9e9e with SMTP id 38308e7fff4ca-321dc985bffmr970771fa.35.1746213346287;
        Fri, 02 May 2025 12:15:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1746213346; cv=none;
        d=google.com; s=arc-20240605;
        b=JIadcQQz+fkNHIK83ECeiCrED6M5in+3akfJzV6n1UlxAxKQ5ih94B0ipA8CWQ2S6K
         dUQYy5ehBHJK6cI2QT8wsDHmQca8HU/n44ebxrhVuUfyvo+OWwH8v/g/ACadqacFJLTR
         ZGhwO78zxpfp/HQVUTChMy6p40nyYnZspF0JvqmcE4M1o5APR2KCKbmR8KhVnE0TOj03
         UjGXsq4t6Uq6avgCWDfzoykPji+oFFSgljIH6lFxhqfepBu6X5Rj1cED8lWgTw4TQd8g
         zu69Cea57wPKLB5Z8cfh0pLXnkwghq0BMRP++rj7DcPOOYmFhHPy+yofqC0wkdk4GkTQ
         qYkA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=G+Z/WZ5id8MeN1r9HvnGWUJnI1v0qf3Qjz6fVIBzkzM=;
        fh=buJUvwPPgdi5Z5zmcvUt6NajLrOVgzwZz6n1oNFrtB8=;
        b=L8X+/7oCLNUSpw3LQnSvFCUEkQYQ8C6RZgMqx3GOFgHFS867fS4bX0XS9gUZXcy+Xb
         Nz43YDjrE9/4mQoqEJrNVrIbJjCrAWeIRTV81DjZ0fRZhXSz1KMJ5CJSbAHS+Aosj6vE
         wOadhzMly+A/xsJwSf7aj3kKTcRuEHnZusbea6wQb+6MBIFL64cDDDlQDD5Y6TDR/sD2
         dXizMS4CT43Cq/bGOivyvFcxDmzlx0S9teWI0zm8yP8TKenRUdzCPzKjlyrDpXEormFl
         bIxEP5VdhKM4xsFSVG8RE0eLHAMYbu9DeCSI2nOjYiYzsj4T2CM4IZjS3XpzgCy9q0C7
         ViYg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=b6b1+FAw;
       spf=pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com. [2a00:1450:4864:20::52d])
        by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-320263e99cesi519411fa.0.2025.05.02.12.15.46
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 02 May 2025 12:15:46 -0700 (PDT)
Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d as permitted sender) client-ip=2a00:1450:4864:20::52d;
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5edc07c777eso3462093a12.3
        for <bitcoindev@googlegroups.com>; Fri, 02 May 2025 12:15:46 -0700 (PDT)
X-Gm-Gg: ASbGnct0ydZ2vQABmTi2yeA//s7EyeviMFB6eaLBiuTKyAmPMzrZSMcX68ih5GBmSDt
	c5aueMbTOXcr40oIMC/0rhfCiW6jfvFPeKYDmDk3veaQmLSQplkhhbWLrJxIbh4t+K5OeEgUu2R
	frgPExsZY/GqS04LcTpwde0w==
X-Received: by 2002:a05:6402:1ec8:b0:5fa:a495:6904 with SMTP id
 4fb4d7f45d1cf-5faa80019damr171730a12.23.1746213345262; Fri, 02 May 2025
 12:15:45 -0700 (PDT)
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>
In-Reply-To: <69194329-4ce6-4272-acc5-fd913a7986f3n@googlegroups.com>
From: Saint Wenhao <saintwenhao@gmail.com>
Date: Fri, 2 May 2025 21:15:34 +0200
X-Gm-Features: ATxdqUHHKmcO-8Xzc8g4ErqsH7cXSCOfJGSRyeymcVz1-OACIfx2nLQN4iqJaJg
Message-ID: <CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ+FuWRA@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: multipart/alternative; boundary="0000000000002580b506342bfaf6"
X-Original-Sender: saintwenhao@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=b6b1+FAw;       spf=pass
 (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::52d
 as permitted sender) smtp.mailfrom=saintwenhao@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--0000000000002580b506342bfaf6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> 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=C5=82(a):

> On Friday, May 2, 2025 at 11:01:10=E2=80=AFAM 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 f=
or
> a 1 in 4 billion chance of accidentally accepting an invalid chain. Leavi=
ng
> consensus to chance feels philosophically improper, but it's a pretty saf=
e
> 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 functi=
on
> 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 fini=
te
> 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 har=
d
> 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 t=
he
> 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-fd91=
3a7986f3n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/69194329-4ce6-4272-acc5-fd9=
13a7986f3n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ%2BFuWRA%40mail.gmail.com.

--0000000000002580b506342bfaf6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Is there a faster alternative to sha256?<br><br>Hmm,
 maybe you can avoid hashing at all? If you take txid:vout as it is,=20
then it will take 36 bytes per output, and you can just treat it in the=20
same way, as you would some pseudorandom result of some 288-bit hash=20
function. And then, it is all about mixing the salt with that result.<br><b=
r>Of
 course, then someone could potentially replace &quot;(txid:1) + (txid:4)&q=
uot;=20
with &quot;(txid:2) + (txid:3)&quot;, so maybe it should be replaced with=
=20
something else.<br><br>And also, there are some types of outputs, where=20
you will know in advance, how things will be hashed. Which means, that=20
potentially something like &quot;hashPrevouts&quot; could be used, and then=
 it=20
could make things a little bit faster, if someone will create a=20
transaction, which will spend some coin, because some data will be=20
already hashed, and ready to be fetched. But when I read BIP-143, then=20
it seems, that it could be hard to make such optimizations (but=20
nonetheless, it could be a good hint, to design future protocols in a=20
way, which would make such optimizations possible).</div><br><div class=3D"=
gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">pt=
., 2 maj 2025 o 21:09=C2=A0Greg Maxwell &lt;<a href=3D"mailto:gmaxwell@gmai=
l.com">gmaxwell@gmail.com</a>&gt; napisa=C5=82(a):<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div><div dir=3D"auto">On Friday, May 2,=
 2025 at 11:01:10=E2=80=AFAM UTC Ruben Somsen wrote:<br></div><blockquote s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>I don&#39;t see a practical way to do =
this without compromising the benefits of SwiftSync because of the=C2=A0&qu=
ot;later find them being spent&quot; part. For one, it would require doing =
a lookup for each input to see if it&#39;s in your UTXO set, something we c=
urrently don&#39;t need to do at all. Secondly, it would require blocks to =
be processed in order, limiting parallelization. The space savings would al=
so be negligible, considering the hint data is already &lt;100MB (compresse=
d).</div></div></blockquote><div><br></div><div>Doh. Right. Got too excited=
.</div><div>=C2=A0<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv>I think most of the remaining optimization potential (other than the eng=
ineering work to enable parallel validation) is in the hash aggregate,=C2=
=A0like 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 billio=
n chance of accidentally accepting an invalid chain. Leaving consensus to c=
hance feels philosophically improper, but it&#39;s a pretty safe bet consid=
ering it also involves PoW to trigger and even then would only affect one o=
r two random unlucky people on=C2=A0Earth.</div></div></blockquote><div><br=
></div><div>I think the problem isn&#39;t so much the size of the hash outp=
ut, but rather the property you need is that each salt gives you a differen=
t hash function such that the attacker cannot predictably create collisions=
. The most expedient way to get there is a cryptographic hash function, whi=
ch limits you lower performance choices.=C2=A0 Your reduction function coul=
d 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.</div><div><br></div><div>It=
 doesn&#39;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 fast=
est.=C2=A0 SHA-256 will easily be a winner on hardware with SHA-NI or simil=
ar.=C2=A0 But there are other cryptographic hashes in the codebase that mig=
ht be faster on systems without sha256 hardware support.=C2=A0 <br></div><d=
iv><br></div><div>There are argument I can see to prove the security of sim=
pler hashes that only work if you assume that the attacker could only inser=
t 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 thi=
nk makes it hard to say much positive about the security of any optimizatio=
n except truncating a secure hash (and I don&#39;t think truncating will wi=
n you much security).</div><div><br></div><div>=C2=A0In terms of security k=
eep in mind that a prospective attacker needs to also perform POW to get th=
eir 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&=
#39;t isolated.=C2=A0 This fact could be used to justify a rather weak hash=
 function, but I think it&#39;s not really worth a lot of analysis ahead of=
 the initial functionality.=C2=A0 I&#39;m guessing that once this is implem=
ented, even if its with a quite expensive hash function that the IBD perfor=
mance will be heavily bottlenecked in network and parallelism related issue=
s and be far from the lowest hanging fruit for a while,=C2=A0 considering t=
hat this has eliminated the big sequential part and a number of annoying to=
 optimize components entirely.</div><div><br></div><div><br></div><div><br>=
</div><div><br></div><div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/69194329-4ce6-4272-acc5-fd913a7986f3n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/69194329-4ce6-4272-acc5-fd913a7986f3n%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ%2BFuWRA%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CACgYNOLqLbemTBbnC-63vXUfCebDPLevxJ4U9j3XM6mQ%2BFuWRA%40ma=
il.gmail.com</a>.<br />

--0000000000002580b506342bfaf6--