path: root/6c/1bbf47eed7f25f73bab453301d3c4ddb4170ae

Return-Path: <ademan555@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DE91BC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 Dec 2023 18:21:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id AC5F94048A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 Dec 2023 18:21:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AC5F94048A
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=CeYsNlgA
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Zwuqrer2L-W8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 Dec 2023 18:21:44 +0000 (UTC)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com
 [IPv6:2a00:1450:4864:20::230])
 by smtp2.osuosl.org (Postfix) with ESMTPS id EC50440370
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 Dec 2023 18:21:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EC50440370
Received: by mail-lj1-x230.google.com with SMTP id
 38308e7fff4ca-2ca00dffc23so76317171fa.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 12 Dec 2023 10:21:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1702405301; x=1703010101;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=2bIsbfSsI4k9szW1EreWQfghjYXhd2G0tFf8NGno39U=;
 b=CeYsNlgAZUXcblqa5nF4YhlNJ8f6xfpDkipaDh+PqgmVkC5POe4qK+8FG+5gaI9m2A
 Q78sn69poPCSdVcXZqs/gGxWkWWYTDh07sVPLqXYpYs76tXpnEvwFExN2Dn5a2Dnze34
 ycIxNa8xwlSeSq5MkvsTN1MW8LlwTQfxsH27w5Czs6oLa/WukrxsXwR++jgStFO/tz1z
 7M3vM6xiSH5f3kPSC5JL9aR2asKlkYv7CRGVrF0AeUT/oBQujJS7QVYIFQf5GZAj54ki
 7HD/2ra3WoaFNa5z6mULRVRDWBdueSYq2uVLholPEcovUPz+GikLDegcLvsrAES++p4/
 UQhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1702405301; x=1703010101;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=2bIsbfSsI4k9szW1EreWQfghjYXhd2G0tFf8NGno39U=;
 b=iWa/optx3A+8vss1kzy6os0Y6WFKrP5ljpI90dKjCHVBXuCGADwMAvNLZg1EnmlhbO
 T7YppsmpL1KmMLX2fFuluYO1X/81ij+fd8SzOsLbqTnwsnm7sR/dKPJDWahhvZ76t+3U
 ODTo3T/LuJ0NLEvZyfkVTfLkQlWiGXWuarQ8bxo9Rg5MNARR69YPX1WvPhHRxBl6fwS4
 G9tGwEoMdMrB+2JMX4yn66wnX13VWQZrnqUAXK7RCBjBbOZqHSqJpfacriyPjwxAYx+q
 RxZfnKusSzRQQfU2u9o7iI63zcYnxTWuTMsIZHYNnNrnQgJe1JWqnHFm51vpTicwvFP0
 GsoA==
X-Gm-Message-State: AOJu0YyvEk25d3BvZf86grPpCLNho+QjBdMSSzBVa095ji9fwX/QeQbp
 qdFhQFoikS7VQmpU8diqZysspg3K5WPS4Dnl13KHF1XhY0k=
X-Google-Smtp-Source: AGHT+IHTYgpfqhaP4HunEqn5+7bbfAlkFQVqikc3PGifHK1uk93KprwmTyWoZBgGkp2LsymH1FOR9xrylDRZdEG2bnU=
X-Received: by 2002:a2e:a103:0:b0:2cb:54a9:77d6 with SMTP id
 s3-20020a2ea103000000b002cb54a977d6mr3511269ljl.7.1702405301101; Tue, 12 Dec
 2023 10:21:41 -0800 (PST)
MIME-Version: 1.0
From: Ademan <ademan555@gmail.com>
Date: Tue, 12 Dec 2023 12:21:29 -0600
Message-ID: <CAKwYL5Fu-02SUmdw8u_mkjJDQoC5txi7XTEju6=gL2MFbRBsxw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 steven@stevenroose.org
Content-Type: multipart/alternative; boundary="0000000000003c6804060c541f61"
X-Mailman-Approved-At: Wed, 13 Dec 2023 11:02:56 +0000
Subject: Re: [bitcoin-dev] bip-0127 "Simple Proof-of-Reserves Transactions"
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Dec 2023 18:21:46 -0000

--0000000000003c6804060c541f61
Content-Type: text/plain; charset="UTF-8"

Hi Everyone,
    I hope this is the correct venue for discussion, I've been vomiting
half-thoughts into #bitcoin-wizards for months now and I realize I should
probably get over my aversion to the permanence of the ML since IRC is too
synchronous.This might be too much about implementation and too little
concept/theory but I'll leave that decision to the ML mods.

I'm in the process of exploring proof-of-reserves, specifically with
bip-0127 and bdk-reserves (does not claim to be a 100% implementation of
bip-0127, only inspired by it) and I had a few questions/comments on the
bip. Maybe a couple of them are worth clarifying in the bip itself (or
maybe they're just dumb questions). These are in order of the bip's text,
but *question 3 is the most important to me.*

1. sha256 vs double sha256?

> the txid part should be SHA-256("Proof-of-Reserves: Some Message") with
the string encoded as UTF-8.

*Are there merits to SHA-256(m) over SHA-256(SHA-256(m)) aside from
marginal efficiency? Any drawbacks?* My immediate gut reaction was that it
should be double sha256 and it looks like the bdk-reserves implementor
agreed. However, I concede my gut (and in fact my brain as well) are not
particularly good at designing and evaluating cryptographic protocols.

2. output script pubkey?

> The transaction MUST have a single output that is the exact sum of all
the inputs

*What should that output's scriptPubkey be?* bdk-reserves selected an
impossible* to spend p2wpkh script, but couldn't it just as easily be an
empty OP_RETURN? I suppose since the entire transaction is invalid, there
is no requirement that the output be unspendable either. *Would it be
beneficial to recommend an output scriptPubkey in the bip?* (or multiple,
one with SHOULD and the other with MAY ?)

3. validating that inputs commit to the commitment input?

> [The remaining inputs] MUST have signatures that commit to the commitment
input (e.g. using SIGHASH_ALL).

With only the final transaction available, validating that all signatures
use SIGHASH_ALL, except for simple cases like p2pkh and p2wpkh is very
difficult. In bdk-reserves we have libbitcoinconsensus available and use it
for validation of non-commitment inputs. Despite the duplicated validation
time, *does it make sense to malleate the commitment input, then
re-validate all inputs, counting any successful validations as failures? *I
think this is generally a good approach, as it will also reject things like
lightning anchor outputs if they managed to persist on chain, but can
anyone think of a false-negative this approach would produce?

Assuming this approach is acceptable, *what would the ideal malleation look
like?* Tentatively I prepended "MALLEATED" to the commitment string and
re-hashed it, but I suppose setting the txid to a constant like 00000...
might work just as well?

4. conveying data in the commitment message?

*Finally, if I want to commit to data in the commitment message, does
anyone have recommendations on format?* This is probably beyond the scope
of the BIP, and a bit of bikeshedding, but I want to commit to a number of
pieces of information in the commitment (such as the current time, and an
identity pubkey which will be used later in my protocol), and the verifier
should retrieve and verify them.

I could construct an ad-hoc format for the message and parse that, but
something like "Proof-of-Reserves: " || base64(json_data) or even simply
"Proof-of-Reserves: " || json_data is attractively simple to implement.
What have other implementors done? Do you have any recommendations? In my
case the challenge doesn't need to be human readable, so any and all
options are usable as far as I can tell.

I suppose alternatively, the prover could communicate this data out of band
(instead of the commitment message directly), and the verifier would use
the same format and algorithm to construct the commitment message, which
means an ad-hoc format would work fine. I think I'm leaning in this
direction now. Thoughts?

Hopefully that is roughly up to the standards of the list, thanks in
advance for any input.

Thanks,
Dan

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

<div dir=3D"ltr"><div>Hi Everyone,</div><div>=C2=A0=C2=A0=C2=A0 I hope this=
 is the correct venue for discussion, I&#39;ve been vomiting half-thoughts =
into #bitcoin-wizards for months now and I realize I should probably get ov=
er my aversion to the permanence of the ML since IRC is too synchronous.Thi=
s might be too much about implementation and too little concept/theory but =
I&#39;ll leave that decision to the ML mods.</div><div><br></div><div>I&#39=
;m in the process of exploring proof-of-reserves, specifically with bip-012=
7 and bdk-reserves (does not claim to be a 100% implementation of bip-0127,=
 only inspired by it) and I had a few questions/comments on the bip. Maybe =
a couple of them are worth clarifying in the bip itself (or maybe they&#39;=
re just dumb questions). These are in order of the bip&#39;s text, but <b>q=
uestion 3 is the most important to me.</b><br></div><div><br></div><div>1. =
sha256 vs double sha256?<br><br></div><div>&gt; the txid part should be SHA=
-256(&quot;Proof-of-Reserves: Some Message&quot;) with the string encoded a=
s UTF-8.<br> <br><b>Are there merits to SHA-256(m) over SHA-256(SHA-256(m))=
 aside from marginal efficiency? Any drawbacks?</b> My immediate gut reacti=
on was that it should be double sha256 and it looks like the bdk-reserves i=
mplementor agreed. However, I concede my gut (and in fact my brain as well)=
 are not particularly good at designing and evaluating cryptographic protoc=
ols.<br><br></div><div>2. output script pubkey?</div><div>=C2=A0<br></div><=
div>&gt; The transaction MUST have a single output that is the exact sum of=
 all the inputs<br><br><div><b>What should that output&#39;s scriptPubkey b=
e?</b> bdk-reserves selected an impossible* to spend p2wpkh script, but cou=
ldn&#39;t it just as easily be an empty OP_RETURN? I suppose since the enti=
re transaction is invalid, there is no requirement that the output be unspe=
ndable either. <b>Would it be beneficial to recommend an output scriptPubke=
y in the bip?</b> (or multiple, one with SHOULD and the other with MAY ?)<b=
r></div><div><br></div><div>3. validating that inputs commit to the commitm=
ent input?<br></div><div><br>&gt; [The remaining inputs] MUST have signatur=
es that commit to the commitment input (e.g. using SIGHASH_ALL).<br><br></d=
iv><div>With only the final transaction available, validating that all sign=
atures use SIGHASH_ALL, except for simple cases like p2pkh and p2wpkh is ve=
ry difficult. In bdk-reserves we have libbitcoinconsensus available and use=
 it for validation of non-commitment inputs. Despite the duplicated validat=
ion time, <b>does it make sense to malleate the commitment input, then re-v=
alidate all inputs, counting any successful validations as failures? </b>I =
think this is generally a good approach, as it will also reject things like=
 lightning anchor outputs if they managed to persist on chain, but can anyo=
ne think of a false-negative this approach would produce?<br></div><div><br=
></div><div>Assuming this approach is acceptable, <b>what would the ideal m=
alleation look like?</b> Tentatively I prepended &quot;MALLEATED&quot; to t=
he commitment string and re-hashed it, but I suppose setting the txid to a =
constant like 00000... might work just as well?<br></div><div><br></div><di=
v>4. conveying data in the commitment message?<br></div><div><br></div><div=
><b>Finally, if I want to commit to data in the commitment message, does an=
yone have recommendations on format?</b> This is probably beyond the scope =
of the BIP, and a bit of bikeshedding, but I want to commit to a number of =
pieces of information in the commitment (such as the current time, and an i=
dentity pubkey which will be used later in my protocol), and the verifier s=
hould retrieve and verify them.<br></div><div><br></div><div>I could constr=
uct an ad-hoc format for the message and parse that, but something like &qu=
ot;Proof-of-Reserves: &quot; || base64(json_data) or even simply &quot;Proo=
f-of-Reserves: &quot; || json_data is attractively simple to implement. Wha=
t have other implementors done? Do you have any recommendations? In my case=
 the challenge doesn&#39;t need to be human readable, so any and all option=
s are usable as far as I can tell.<br><br> I suppose alternatively, the pro=
ver could communicate this data out of=20
band (instead of the commitment message directly), and the verifier would u=
se the same format and algorithm to construct the=20
commitment message, which means an ad-hoc format would work fine. I think I=
&#39;m leaning in this direction now. Thoughts?<br></div><div><br></div><di=
v>Hopefully that is roughly up to the standards of the list, thanks in adva=
nce for any input.<br></div><div><br></div><div>Thanks,</div><div>Dan<br></=
div></div></div>

--0000000000003c6804060c541f61--