public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: praxeology_guy <praxeology_guy@protonmail.com>
To: "bfd@cock.lu" <bfd@cock.lu>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives
Date: Sat, 01 Apr 2017 21:10:53 -0400	[thread overview]
Message-ID: <Agqv6Is87aXmNkFS0XphXWCE2TTZuuRJP8shQaomIUqx6W789WvMwflWqnSCQCwLPglEJ2rq3SkF-8tzYaZixbW9Ph-6u4a6sRCu4w-fPmA=@protonmail.com> (raw)
In-Reply-To: <d89b85f6e5dbeaefc6402596dfc3c843@cock.lu>

[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]

Not sure if you are BFD or BF Trolling D, BFTD. But I will bite this time.

Sorry I mistakenly forgot to change the subject back to "A Better MMR Definition" when I decided to send the email to the dev list instead of directly to Peter. So then you made such a reply without knowing context.

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.

Hope that... clears it up for you.

Cheers,
P. Guy

-------- Original Message --------
Subject: Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives
Local Time: April 1, 2017 6:38 PM
UTC Time: April 1, 2017 11:38 PM
From: bfd@cock.lu
To: praxeology_guy <praxeology_guy@protonmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

If a wallet is unaware of spends of its own coins (ie, transactions
were made it can't have known about), there's probably bigger problems
going on. You might enjoy the topic on this mailing list on committed
bloom filters however, as this solves a similar issue without needing
an ever-growing list of hundreds of millions of spent outputs.

On 2017-04-02 06:04, praxeology_guy via bitcoin-dev wrote:
> Bitcoin nodes could also keep a spentness status list, where each bit
> in the spentness status list corresponds to whether a txo in the MMR
> is spent. This could make it so that disconnected wallets didn't have
> to guess the pruned relative spentness status when it reconnects to
> the network... and help prevent DoS attacks.

[-- Attachment #2: Type: text/html, Size: 2609 bytes --]

  reply	other threads:[~2017-04-02  1:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-01 20:04 [bitcoin-dev] Guessing the spentness status of the pruned relatives praxeology_guy
2017-04-01 23:38 ` bfd
2017-04-02  1:10   ` praxeology_guy [this message]
2017-04-02  1:27     ` Bram Cohen
2017-04-02  1:58       ` praxeology_guy
2017-04-02  2:18         ` Bram Cohen
2017-04-02  3:37           ` praxeology_guy
2017-04-02 20:43             ` praxeology_guy
2017-04-03  3:13               ` Bram Cohen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='Agqv6Is87aXmNkFS0XphXWCE2TTZuuRJP8shQaomIUqx6W789WvMwflWqnSCQCwLPglEJ2rq3SkF-8tzYaZixbW9Ph-6u4a6sRCu4w-fPmA=@protonmail.com' \
    --to=praxeology_guy@protonmail.com \
    --cc=bfd@cock.lu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox