You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compact blocks that contain no shielded inputs or outputs do not cause any updates to wallet state. On testnet, purely-transparent blocks are very common, but wallets still have to download all of these compact blocks even though they can have no effect. When using the compact block protocol, it would be completely fine to skip all such blocks (doing so reveals no information, because every wallet using the compact block protocol would do so if possible), so lightwalletd should provide a way for wallets to entirely filter out these blocks and never download them.
The text was updated successfully, but these errors were encountered:
Sounds like an easy and useful change. You say "should provide a way", so should we make this change backward-compatible? Don't provide these blocks only if explicitly asked not to (but otherwise behave the same as today)?
Yeah, we probably need this to be backwards compatible. If we just start skipping blocks entirely it'll foul up a bunch of stuff. Also we need to figure out how to handle issues around chain continuity before we move forward with implementation; I just created this ticket so that I wouldn't forget about it.
Compact blocks that contain no shielded inputs or outputs do not cause any updates to wallet state. On testnet, purely-transparent blocks are very common, but wallets still have to download all of these compact blocks even though they can have no effect. When using the compact block protocol, it would be completely fine to skip all such blocks (doing so reveals no information, because every wallet using the compact block protocol would do so if possible), so
lightwalletd
should provide a way for wallets to entirely filter out these blocks and never download them.The text was updated successfully, but these errors were encountered: