praxeology_guy [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-01 📝 Original message:Not sure if you are BFD or ...
📅 Original date posted:2017-04-01
📝 Original message: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 at cock.lu
To: praxeology_guy <praxeology_guy at protonmail.com>, Bitcoin Protocol Discussion <bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/050e506f/attachment-0001.html>;
📝 Original message: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 at cock.lu
To: praxeology_guy <praxeology_guy at protonmail.com>, Bitcoin Protocol Discussion <bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170401/050e506f/attachment-0001.html>;