Thanks, great to hear!

If isRequiringUpdateAllBloomFilter() returns true a BLOOM_UPDATE_ALL
filter is constructed. It won't stay like this though. I guess in future
we will ask a Wallet's KeyChainGroups if at least one of them requires
an 'update all' filter.


On 04/14/2018 07:53 PM, Anton wrote:
> Yes, changes introduced in
> https://github.com/schildbach/bitcoinj/commit/66d76131a6b453b27d1344a71665b6050c201c43
> also fix this issue.
> Just in case, I see "plus the BLOOM_UPDATE_ALL flag set" in commit
> comments but no such changes in 66d76131a6b453b27d1344a71665b6050c201c43
> itself, am I missing something?
> 
> суббота, 14 апреля 2018 г., 3:40:52 UTC+3 пользователь Andreas
> Schildbach написал:
> 
>     Investigating more into this... actually the correct way to deal with
>     bloom filters is inserting UTXO OutPoints into the filter.
> 
>     And bitcoinj already has a mechanism for this, which is currently only
>     used for watched scripts.
> 
>     Can you the top commit from my branch?
>     https://github.com/schildbach/bitcoinj/tree/p2wpkh-bloom-filter
>     <https://github.com/schildbach/bitcoinj/tree/p2wpkh-bloom-filter>
> 
>     (Obviously for isRequiringUpdateAllBloomFilter() we need a more
>     appropriate solution, rather than just returning true. But for a quick
>     test it should do.)
> 
>     I'm looking forward to your findings.
> 
> 
>     On 04/10/2018 06:51 PM, Anton wrote:
>     > Thanks for the suggestion,
>     >
>     > tx.addOutput(Coin.ZERO, new
>     > ScriptBuilder().op(OP_RETURN).data(pubKeyHash).build());
>     >
>     > does the job.
>     >
>     > Of course, I'm interested to know whether a less hacky solution
>     exists.
>     >
>     > вторник, 10 апреля 2018 г., 18:42:10 UTC+3 пользователь Andreas
>     > Schildbach написал:
>     >
>     >     [+cc Jonas Schnelli, as I discussed this topic with him last
>     year.]
>     >
>     >     Hmmm, indeed that sounds bad. I totally overlooked this case.
>     Seems
>     >     like
>     >     BIP37 needs to be amended to include the witness in filter
>     matching.
>     >     However, on nodes that prune the witnesses this won't work
>     either.
>     >
>     >     P2WPKH-P2SH doesn't seem to have this problem, as it contains the
>     >     20-byte key hash in its scriptSig.
>     >
>     >     Of course as a workaround you could make sure there is always
>     a change
>     >     back to you. Maybe to not waste coins/UTXOs create an OP_RETURN
>     >     containing one of the pubkeys?
>     >
>     >     I wonder if the new client-side filtering (BIP157) has the same
>     >     problem?
>     >
>     >
>     >     On 04/09/2018 05:51 PM, Anton wrote:
>     >     > I'm currently experimenting with making a native segwit
>     wallet here:
>     >     > https://github.com/btcontract/bitcoinj
>     <https://github.com/btcontract/bitcoinj>
>     >     <https://github.com/btcontract/bitcoinj
>     <https://github.com/btcontract/bitcoinj>> by merging current master
>     with
>     >     > segwit address support and a
>     >     > https://github.com/bitcoinj/bitcoinj/tree/segwit
>     <https://github.com/bitcoinj/bitcoinj/tree/segwit>
>     >     <https://github.com/bitcoinj/bitcoinj/tree/segwit
>     <https://github.com/bitcoinj/bitcoinj/tree/segwit>> branch.
>     >     > I've got to a point where wallet can receive and send
>     transactions
>     >     but
>     >     > have stumbled into an issue which may become relevant once
>     bitcoinj
>     >     > master starts supporting native segwit wallets.
>     >     >
>     >     > The issue is that once a transaction without change (the one
>     which
>     >     > empties a wallet) is sent out it won't be seen by wallet
>     again after
>     >     > blockchain rescan or restoring from seed.
>     >     >
>     >     > As far as I understand the issue is two-fold:
>     >     > 1. tx scriptSig is empty and does not contain a relevant
>     `pubKey`
>     >     (it's
>     >     > located in a witness).
>     >     > 2. none of tx outputs contain `pubKeyHash`es relevant to a
>     wallet.
>     >     >
>     >     > Any thoughts if my understanding is correct and what can be
>     done
>     >     about it?
>     >     >
>     >     > --
>     >     > You received this message because you are subscribed to the
>     Google
>     >     > Groups "bitcoinj" group.
>     >     > To unsubscribe from this group and stop receiving emails
>     from it,
>     >     send
>     >     > an email to bitcoinj+u...@googlegroups.com
>     >     > <mailto:bitcoinj+u...@googlegroups.com>.
>     >     > For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>
>     >     <https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>>.
>     >
>     >
>     > --
>     > You received this message because you are subscribed to the Google
>     > Groups "bitcoinj" group.
>     > To unsubscribe from this group and stop receiving emails from it,
>     send
>     > an email to bitcoinj+u...@googlegroups.com
>     > <mailto:bitcoinj+u...@googlegroups.com>.
>     > For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "bitcoinj" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to bitcoinj+unsubscr...@googlegroups.com
> <mailto:bitcoinj+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bitcoinj+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to