From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id DE91BC0037 for ; 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 ; 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 ; 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 ; 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 ; 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 Date: Tue, 12 Dec 2023 12:21:29 -0600 Message-ID: To: Bitcoin Protocol Discussion , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hi Everyone,
=C2=A0=C2=A0=C2=A0 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 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'll leave that decision to the ML mods.

I'= ;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'= re just dumb questions). These are in order of the bip's text, but q= uestion 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 a= s UTF-8.

Are there merits to SHA-256(m) over SHA-256(SHA-256(m))= aside from marginal efficiency? Any drawbacks? 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.

2. output script pubkey?
=C2=A0
<= div>> The transaction MUST have a single output that is the exact sum of= all the inputs

What should that output's scriptPubkey b= e? bdk-reserves selected an impossible* to spend p2wpkh script, but cou= ldn'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. Would it be beneficial to recommend an output scriptPubke= y in the bip? (or multiple, one with SHOULD and the other with MAY ?)

3. validating that inputs commit to the commitm= ent input?

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

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, does it make sense to malleate the commitment input, then re-v= alidate 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 anyo= ne think of a false-negative this approach would produce?
Assuming this approach is acceptable, what would the ideal m= alleation look like? Tentatively I prepended "MALLEATED" 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?

4. conveying data in the commitment message?

Finally, if I want to commit to data in the commitment message, does an= yone 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 i= dentity pubkey which will be used later in my protocol), and the verifier s= hould retrieve and verify them.

I could constr= uct an ad-hoc format for the message and parse that, but something like &qu= ot;Proof-of-Reserves: " || base64(json_data) or even simply "Proo= f-of-Reserves: " || json_data is attractively simple to implement. Wha= t 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 option= s are usable as far as I can tell.

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= 'm leaning in this direction now. Thoughts?

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

Thanks,
Dan
--0000000000003c6804060c541f61--