Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A37240C for ; Sun, 2 Apr 2017 01:27:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C1511D7 for ; Sun, 2 Apr 2017 01:27:18 +0000 (UTC) Received: by mail-io0-f173.google.com with SMTP id b140so58584458iof.1 for ; Sat, 01 Apr 2017 18:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bittorrent-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4UR83pCYudtrKvLQU5Ogm8LW1TYtIOjdbN7ye321TQM=; b=dLSZZnc/Aw1A4RsmSucQCu/x9dkNDHEpCmVmkOM7S0+eqvSYkL/daN1zSVou3tVhDZ NeWokNBHWcc+Mr7BUbr6pnUz36OdEjBuX5x1b+Ieypur+znNufEwvW3yhiu0dyIoPEet 9erITct1JPmVFswtq5uDp1PTLomcdS9z0bjpMm1opAmXCt9XHKIuKQMEJIHTjsQdr9nq L3zLxK5OmTkkc7Z5skKQLiH3Th9V6kAQ+Z7cPJSWb9ep0P8rbtRPTP+asU5+r4ScSau5 cY6C0NIb7xNqY9fhF0tJAA8AsG4tx9o3dBz232PCKFk8rwWlvWrhgXvcCxuIt6eetGej rEBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4UR83pCYudtrKvLQU5Ogm8LW1TYtIOjdbN7ye321TQM=; b=UMIdGvzSIUrHFyJpvSlOa++wZHPeAH6ONcw0Z6lIXosAAYbvGMaMymgsd41DbY3J5j n81TZt6rQ3dDk6MXYiJyqCSZsJp9mkjugRSJ+C/eEW83m7ZiVutWJbVutl08MtUJhRRb MvZ3H2kdGZPHXBgP9nr8lnvx7dUo+VN2Xrcr+l8BJjcywK9FGt2y3c4Tg3MFiBBiqsOj J0zkCeTPKYgv7rL1kVPVssFuYpaHi7Q6Jvbk7g4WBJ7VSb7HufuunMNtpkvUw6YCU0g9 p76napbreevVwxiW4qy1BGnbtZzEAyrZqeHYcT4c2wGECQCg7BnXzL4S7qX3cCzsmWWH qLlg== X-Gm-Message-State: AFeK/H2DyP0+DKeIcZMZyGrjbZooK4YvrfpNsBrohVYvTYjsUVPc682o0/IYnZNDfVTPzd+fcn/dB0/H5hZTOMPQ X-Received: by 10.107.50.206 with SMTP id y197mr10867446ioy.214.1491096437874; Sat, 01 Apr 2017 18:27:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.184.70 with HTTP; Sat, 1 Apr 2017 18:27:17 -0700 (PDT) In-Reply-To: References: From: Bram Cohen Date: Sat, 1 Apr 2017 18:27:17 -0700 Message-ID: To: praxeology_guy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114479548185c2054c24f1a6 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives 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: Sun, 02 Apr 2017 01:27:19 -0000 --001a114479548185c2054c24f1a6 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 1, 2017 at 6:10 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > With using the MMR data structure for txo commitments, its preferable that > wallets only keep information pertinent to their own spendable coins. In > previous communication we talked about how wallets could maintain the > changing MMR proof for their old coins. Yes wallets know which of their > own coins are spent. But with MMR proofs wallets also need to know the > spentness status of close relatives in the MMR tree... in order to > construct a valid MMR proof that their own coin is not spent. > Did you read the post that I made about the TXO bitfield yesterday? That gives what I believe is a much better way of handling this whole issue, allowing wallets to keep track of nothing other than the proof of position of their txo, which never changes. --001a114479548185c2054c24f1a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Apr 1, 2017 at 6:10 PM, praxeology_guy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

With using the MMR data struct= ure for txo commitments, its preferable that wallets only keep information = pertinent to their own spendable coins.=C2=A0 In previous communication we = talked about how wallets could maintain the changing MMR proof for their ol= d coins.=C2=A0 Yes wallets know which of their own coins are spent.=C2=A0 B= ut with MMR proofs wallets also need to know the spentness status of close = relatives in the MMR tree... in order to construct a valid MMR proof that t= heir own coin is not spent.

Did y= ou read the post that I made about the TXO bitfield yesterday? That gives w= hat I believe is a much better way of handling this whole issue, allowing w= allets to keep track of nothing other than the proof of position of their t= xo, which never changes.
--001a114479548185c2054c24f1a6--