<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">I was wondering why this multi-layer multi-block filter proposal isn&#39;t getting any comment,</div><div style="font-size:small">is it because not asking all filters is leaking information?</div></div></blockquote><div><br></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">It&#39;s an interesting idea, but it adds more complexity to the client and could be added later on if clients adopt BIP 157 and complain about bandwidth. It also derives all bandwidth gains from address reuse. So I&#39;m hesitant to make the complexity tradeoff for bandwidth savings due to a behavior that is actively discouraged.</span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">On another note, I&#39;ve been thinking that block TXO commitments could resolve the issue we are facing now with deciding between the prev script approach and outpoint. The whole argument for outpoints is that there are compact-ish (&lt;1 MiB) proofs of filter validity, which is not currently possible if the filters included prev output data. Such proofs would be feasible if blocks headers (well, actually coinbase txs) had a commitment to the Merkle root of all newly created outputs in the block.</span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">This idea has been tossed around before in the context of fraud proofs and TXO bitfields, and seems to unlock a whole bunch of other P2P commitments. For example, if we wanted to do P2P commitments (BIP 157-style) to the distribution of tx fees in a block, one could use block TXO commitments to prove correctness of fees for non-segwit txs. It also enables block validity proofs (assuming parent blocks are valid), which are not as powerful as invalidity/fraud proofs, but interesting nonetheless.</span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div><span style="color:rgb(34,34,34);font-family:sans-serif;font-size:13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">This would require a new getdata type BLOCK_WITH_PREVOUTS or something. I assume for most coinbase-tx-committed proposals, we&#39;ll also need a new getcoinbases/coinbases that requests the coinbase tx and Merkle branch for a range of headers as well. But with these additions, we could start serving more block-derived data to light clients under the BIP 157 at-least-one-honest-peer assumption.</span></div></div></div>