I agree with Greg and Laolu; BIP-37 filtering for transactions is no better than for blocks and completely destroys privacy.

A constant stream of transactions is OK, but even cheaper for light clients would be Laolu's proposal of streaming more tx data than existing inv messages but less than existing tx messages.

We could make a bit field of things to include in every inv-with-metadata message, such as:
- witness data
- scriptSig data pushes
- scriptPubKey
- hash of scriptPubKey (unnecessary if full scriptPubKey is sent)
- scriptPubKey data pushes
- etc.

This way a full node might be able to tell what application (or type of application) a light client is running, but not the client's addresses or outputs, except maybe when the client originates transactions.

On Thu, Jun 1, 2017 at 10:28 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, Jun 2, 2017 at 2:15 AM, Chris via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
>
>> One aspect which isn't in this BIP draft is direct support for unconfirmed
>> transactions. I consider such a feature an important UX feature for mobile
>> phones, and something which I've personally seen as an important
>> UX-experience when on-boarding new users to Bitcoin.
>
> Totally agree. My first thought is maybe you could keep bip37 filtering
> as optional for unconfirmed transactions. Since you're only interested

Really bad for privacy. Data for transactions at the tip is only
14kb/s-- potentially less if segwit is in use and you're not getting
witnesses. Is that really that burdensome?

FWIW, leaving a mobile browser just running while pointed at some
websites seems to use more traffic than that just loading advertising.
:)
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev