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

2019-07-26 Thread Tamas Blummer via bitcoin-dev
Hi Chris,

yes, fidelity bonds can impose cost to make sybill attacks more expensive 
therefore less likely.
I prefer the flavor with CHECKSEQUENCEVERIFY which imposes opportunity cost, 
just as effective
as burning, but is sustainable.

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 additional market of locking UTXOs in exchange of a 
payment.

This would give rise to a transparent interest rate market for Bitcoin an 
additional huge benefit.

Regards,

Tamas Blummer

> On Jul 25, 2019, at 13:47, Chris Belcher via bitcoin-dev 
>  wrote:
> 
> JoinMarket[1] can be sybil attacked today at relatively low cost which
> can destroy its privacy. Bitcoins can be sacrificed with burner outputs
> and time-locked addresses (also called fidelity bonds), and this can be
> used to greatly improve JoinMarket's resistance to sybil attacks.
> 
> With real-world data and realistic assumptions we calculate that under
> such a fidelity bond system an adversary would need to lock up
> 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner
> addresses to have a good chance of sybil attacking the system if it were
> added to JoinMarket.
> 
> This increased resistance to sybil attacks would most likely cause
> coinjoin fees to rise. I think the added cost is worth it for the
> greatly improved privacy, because today miner fees are the biggest cost
> to JoinMarket takers not coinjoin fees which are very low. Users should
> definitely share their opinion on fees after reading the document.
> 
> ## Introduction
> 
> JoinMarket creates a market for coinjoins, allowing anyone to create
> equal-amount coinjoins for any amount they want at any time they want.
> In return they pay a fee for the liquidity made available to them. The
> project has existed since 2015 and has probably created hundreds of
> thousands of coinjoins since then. Today there is available liquidity
> for creating coinjoins with amounts up to about 400 btc per coinjoin output.
> 
> ### Sybil attacks
> 
> JoinMarket, like many other schemes where participants are free to
> anonymously enter, can be targetted by sybil attacks. In JoinMarket this
> would work by an attacker running lots of maker bots which attempt to be
> all the makers in every coinjoin. If successful the attacker would have
> enough information unmix every coinjoin.
> 
> One way to solve the problem of sybil attacks is centralization. For
> example coinjoins could be constructed on a centralized server. Then
> random anonymous participants cant sybil attack because they can't
> control the coinjoin construction, but this comes at the cost that the
> server can sybil attack very easily. So this solution is probably a bad
> tradeoff.
> 
> In general, sybil attacks are solved by making them expensive. For
> example, bitcoin mining resists sybil attacks because it requires a
> provable sacrifice of electricity to mine. A bitcoin user can calculate
> the actual monetary value that an attacker must spend in order to
> reverse their transaction.
> 
> Likewise in JoinMarket such a sybil attack is not free either as the
> attacker needs to own enough bitcoins to run enough maker bots for all
> the coinjoins.
> 
> ### Today's low cost for sybil attacks
> 
> A paper on JoinMarket [Möser, Malte and Rainer Böhme. “Join Me on a
> Market for Anonymity.” (2016).] calculates the requirement of such a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
> 
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
> 
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
> 
> Apart from the cost to sybil attack being low, there is also the odd
> situation that smaller coinjoin amounts receive less sybil protection
> than large ones. It costs 100x less to sybil attack a transaction of 0.1
> btc than one of 10 btc. Why should smaller amounts receive less
> sybil-resistance and therefore less privacy?
> 
> ### Liquidity
> 
> When creating this project, it was expected that many more people would
> enter the market as makers and so the cost of a sybil attack would be
> very high. That has not happened. One reason is that everyone who wants
> to create a coinjoin is able to even for large amounts. The fundamental
> problem is that takers are paying-for and getting liquidity, but not
> necessarily sybil-resistance.
> 
> Another smaller reason for the low cost of sybil attacks is that many
> people don't want to store too many bitcoins on an computer connected to
> the internet.
> 
> What is 

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

2019-07-26 Thread Tamas Blummer via bitcoin-dev
Hi Justus,

It might be helpful to consult the Rust implementation  of BIP158 here:
https://github.com/rust-bitcoin/rust-bitcoin/blob/master/src/util/bip158.rs

It has a cleaner structure than Core or Neutrino, includes server and client 
side
and passes Core's test vectors.

Regards,

Tamas Blummer

> On Jul 22, 2019, at 17:58, Justus Ranvier via bitcoin-dev 
>  wrote:
> 
> Signed PGP part
> On 7/22/19 12:01 AM, Matt Corallo via bitcoin-dev wrote:
>> Finally, regarding alternatives, the filter-generation code for BIP
>> 157/158 has been in Bitcoin Core for some time, though the P2P serving
>> side of things appears to have lost any champions working on it. I
>> presume one of the Lightning folks will eventually, given they appear to
>> be requiring their users connect to a handful of their own servers right
>> now, but if you really need it, its likely not a ton of work to pipe
>> them through.
> 
> If you want projects to adopt BIP-157/158, you'd do well to fix the
> numerous errors in the specification.
> 
> As it stands right now it is impossible to implement the protocol using
> the specification because he code examples are broken to the point of
> appearing intentionally sabotaged.
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev