From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D7A92F for ; 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 ; 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 To: bitcoin-dev@lists.linuxfoundation.org, Steven Roose Date: Fri, 15 Feb 2019 15:18:18 +0000 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > Buffershttps://github.com/protocolbuffers/protobuf/ 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