diff options
| author | Luke Dashjr <luke@dashjr.org> | 2019-02-15 15:18:18 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-02-15 15:27:01 +0000 |
| commit | b6172cde43fa917630808c9fa75ef1e6d0c66466 (patch) | |
| tree | 3667e5bee5a7751c17273aba5e0ad0dee8976b4f | |
| parent | febdaad2fdb079e27e598511c0715cd2a9b969e9 (diff) | |
| download | pi-bitcoindev-b6172cde43fa917630808c9fa75ef1e6d0c66466.tar.gz pi-bitcoindev-b6172cde43fa917630808c9fa75ef1e6d0c66466.zip | |
Re: [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves Transactions
| -rw-r--r-- | e3/a608a3c8573f9cb59b3340d579124402776d03 | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/e3/a608a3c8573f9cb59b3340d579124402776d03 b/e3/a608a3c8573f9cb59b3340d579124402776d03 new file mode 100644 index 000000000..d6e8ef10a --- /dev/null +++ b/e3/a608a3c8573f9cb59b3340d579124402776d03 @@ -0,0 +1,86 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D7A92F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 15 Feb 2019 15:27:01 +0000 (UTC) +X-Greylist: delayed 00:07:19 by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id CBF19FE + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 15 Feb 2019 15:27:00 +0000 (UTC) +Received: from [2001:470:5:265:a45d:823b:2d27:961c] (unknown + [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id B74E438A0C76; + Fri, 15 Feb 2019 15:18:53 +0000 (UTC) +X-Hashcash: 1:25:190215:bitcoin-dev@lists.linuxfoundation.org::2lR1Be2vrhFli39R:55SK +X-Hashcash: 1:25:190215:stevenroose@gmail.com::J2r6EAi/MxRXmVwX:cnAQo +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, Steven Roose <stevenroose@gmail.com> +Date: Fri, 15 Feb 2019 15:18:18 +0000 +User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) +References: <CAChG=YV2em+6c9P4DEUB1=+ZSEA6S0j9HDuWoKBeRVMmtzaMNg@mail.gmail.com> +In-Reply-To: <CAChG=YV2em+6c9P4DEUB1=+ZSEA6S0j9HDuWoKBeRVMmtzaMNg@mail.gmail.com> +X-KMail-QuotePrefix: > +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="utf-8" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +Message-Id: <201902151518.50135.luke@dashjr.org> +X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Sat, 16 Feb 2019 15:43:25 +0000 +Subject: Re: [bitcoin-dev] [BIP Proposal] Simple Proof-of-Reserves + Transactions +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +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: Fri, 15 Feb 2019 15:27:01 -0000 + +On Tuesday 29 January 2019 22:03:04 Steven Roose via bitcoin-dev wrote: +> The existence of the first input (which is just a commitment hash) ensures +> that this transaction is invalid and can never be confirmed. + +But nodes can never prove the transaction is invalid, thus if sent it, they +will likely cache the "transaction", taking up memory. I'm not sure if this +is an actual problem, as an attacker can fabricate such transactions anyway. + +> #:Not all systems that will be used for verification have access to a full +> index of all transactions. However, proofs should be easily verifiable +> even after some of the UTXOs used in the proof are no longer unspent. +> Metadata present in the proof allows for relatively efficient verification +> of proofs even if no transaction index is available. + +I don't see anything in the format that would prove unspentness... + +> The proposed proof-file format provides a standard way of combining +> multiple proofs and associated metadata. The specification of the format +> is in the Protocol +> Buffers<ref>https://github.com/protocolbuffers/protobuf/</ref> format. + +IIRC, this has been contentious for its use in BIP70 and may hinder adoption. + +> message OutputMeta { +> // Identify the outpoint. +> bytes txid = 1; +> uint32 vout = 2; +> +> // The block hash of the block where this output was created. +> bytes block_hash = 3; + +This isn't really sufficient. There should probably be a merkle proof. + +Luke + |