Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References

2019-07-27 Thread Mike Brooks via bitcoin-dev
Hey ZmnSCPxj, As to your first point. I wasn't aware there was so much volatility at the tip, also 100 blocks is quite the difference! I agree no one could references a transaction in a newly formed blocks, but I'm curious how this number was chosen. Do you have any documentation or code that

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-07-27 Thread David A. Harding via bitcoin-dev
On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote: > A way to create a fidelity bond is to burn an amount of bitcoins by > sending to a OP_RETURN output. Another kind is time-locked addresses > created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being >

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

2019-07-27 Thread Luke Dashjr via bitcoin-dev
On Tuesday 23 July 2019 14:47:18 Andreas Schildbach via bitcoin-dev wrote: > 3) Afaik, it enforces/encourages address re-use. This stems from the > fact that the server decides on the filter and in particular on the > false positive rate. On wallets with many addresses, a hardcoded filter > will

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

2019-07-27 Thread Matt Corallo via bitcoin-dev
This conversation went off the rails somewhat. I don't think there's any immediate risk of NODE_BLOOM peers being unavailable. This is a defaults change, not a removal of the code to serve BIP 37 peers (nor would I suggest removing said code while people still want to use them - the maintenance

Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds

2019-07-27 Thread Dmitry Petukhov via bitcoin-dev
В Fri, 26 Jul 2019 10:10:15 +0200 Tamas Blummer via bitcoin-dev wrote: > Imposing opportunity costs however requires larger time locked > amounts than burning and the user might not have sufficient funds to > do so. This is however not a restriction but an opportunity that can > give rise to an

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

2019-07-27 Thread Chris via bitcoin-dev
On 7/23/19 10:47 AM, Andreas Schildbach via bitcoin-dev wrote: 3) Afaik, it enforces/encourages address re-use. This stems from the fact that the server decides on the filter and in particular on the false positive rate. On wallets with many addresses, a hardcoded filter will be too blurry and

Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default

2019-07-27 Thread Jonas Schnelli via bitcoin-dev
> 1) It causes way too much traffic for mobile users, and likely even too > much traffic for fixed lines in not so developed parts of the world. Yes. It causes more traffic than BIP37. Basic block filters for current last ~7 days (1008 blocks) are about 19MB (just the filters). On top, you will