Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium

2020-10-03 Thread Chris Belcher via bitcoin-dev
Hello list, This email is an appendium or modification of the earlier CoinSwap protocol published on this list. It is intended to fix the problems found in review. (Original email quoted here too) On 11/08/2020 13:05, Chris Belcher via bitcoin-dev wrote: > I'm currently working on implement

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-03 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 03/09/2020 10:45, ZmnSCPxj wrote: > Good morning Chris, > >> A big downside is that it really ruins the property of allowing coins to >> remain unspent indefinitely. That has privacy implications: if a coin >> remains unspent for longer than 2 weeks (or another short locktime)

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-09-03 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 25/08/2020 04:16, ZmnSCPxj wrote: > > Good morning Antoine, > > >> Note, I think this is independent of picking up either relative or absolute >> timelocks as what matters is the block delta between two links. > > I believe it is quite dependent on relative locktimes. >

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-29 Thread Chris Belcher via bitcoin-dev
o. And this would be a privacy > breakdown, as a maker would be able to provoke one, thus constraining every > upstream hops to go onchain with the same hash and revealing the CoinSwap > route. > > Let me know if I reviewed the correct transactions circuit model or > misunderstood a

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-21 Thread Chris Belcher via bitcoin-dev
Hello, On 21/08/2020 05:20, ZmnSCPxj wrote: > Good morning, > > > >> Right, so if the taker uses only a single maker then they must have more >> than one UTXO. > > Spending one UTXO is fine, it is generating a transaction that has one output > that is problematic. > > What needs to happen

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-20 Thread Chris Belcher via bitcoin-dev
Hello Nadav and ZmnSCPxj, On 20/08/2020 22:38, ZmnSCPxj wrote: > Good morning Nadav, > >> Hey Chris and all, >> >> Looking good :) I have one major concern though >> >>>     q = EC privkey generated by maker >>>     Q = q.G = EC pubkey published by maker >>> >>>     p = nonce generated by taker

Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-20 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, Thanks for the review. My comments are inline. On 20/08/2020 12:17, ZmnSCPxj wrote: > Good morning Chris, > > Great to see this! > > Mostly minor comments. > > > >> >> == Direct connections to Alice === >> >> Only Alice, the taker, knows the entire route, Bob and Charlie

[bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

2020-08-11 Thread Chris Belcher via bitcoin-dev
I'm currently working on implementing CoinSwap (see my other email "Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility"). CoinSwaps are special because they look just like regular bitcoin transactions, so they improve the privacy even for people who do

Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-13 Thread Chris Belcher via bitcoin-dev
On 13/06/2020 15:06, ZmnSCPxj wrote: > Good morning Chris, > >> >> Would it be fair to summarize the idea in this way: >> >> CoinSwappers can slow down the CoinSwap process which will give an >> opportunity for makers to use batching. > > I think so. > > Regards, > ZmnSCPxj > It's definitely

Re: [bitcoin-dev] Hiding CoinSwap Makers Among Custodial Services

2020-06-13 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 11/06/2020 12:51, ZmnSCPxj wrote: > Good morning Chris, and bitcoin-dev (but mostly Chris), > > > I made a random comment regarding taint on bitcoin-dev recently: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017961.html > >> For CoinSwap as well, we

Re: [bitcoin-dev] Tainting, CoinJoin, PayJoin, CoinSwap

2020-06-10 Thread Chris Belcher via bitcoin-dev
Hello nopara73, On 10/06/2020 13:32, nopara73 via bitcoin-dev wrote: > The problem with CoinJoins is that desire for privacy is explicitly > signalled by them, so adversaries can consider them "suspicious." PayJoin > and CoinSwap solve this problem, because they are unnoticeable. I think > this

Re: [bitcoin-dev] Question about PayJoin effectiveness

2020-06-10 Thread Chris Belcher via bitcoin-dev
On 10/06/2020 05:01, Mr. Lee Chiffre via bitcoin-dev wrote: > I am trying to learn about payjoin. I have a couple concerns on its > effectiveness. Are my concerns valid or am I missing something? > > concern 1 > If it is known to be a payjoin transaction anyone could determine the > sender the

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 10/06/2020 11:58, ZmnSCPxj wrote: > Good morning Chris, > >>> Let me propose an alternative: swap-on-receive+swap-on-change. >> >> That's an interesting point, thanks for the thought. This scheme might >> not be appropriate for every threat model and use case. >> For example,

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread Chris Belcher via bitcoin-dev
Hello Lee, Thanks for the review. On 10/06/2020 01:43, Mr. Lee Chiffre wrote: > >> >> === Combining multi-transaction with routing === >> >> Routing and multi-transaction must be combined to get both benefits. If >> Alice owns multiple UTXOs (of value 6 BTC, 8 BTC and 1 BTC) then this is >>

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-10 Thread Chris Belcher via bitcoin-dev
Good morning ZmnSCPxj, On 06/06/2020 02:40, ZmnSCPxj wrote: > Good morning Chris, > >> I think I'm having trouble understanding this, does it work like this: >> >> Say we're in the 2-party coinswap case (Alice and Bob) >> >> We have Alice's funding transaction: >> Alice UTXO ---> 2of2 multisig

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-05 Thread Chris Belcher via bitcoin-dev
Good day ZmnSCPxj, >>> But S6 has the mild advantage that all the funding transactions paying to >>> 2-of-2s can appear on the same block, whereas chaining swaps will have a >>> particular order of when the transactions appear onchain, which might be >>> used to derive the order of swaps. >>

Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-06-02 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 31/05/2020 03:30, ZmnSCPxj via bitcoin-dev wrote: > Good morning Ruben and Chris, > I am not in fact convinced that PayJoin-with-CoinSwap adds *that* much > privacy. > > These transactions: > > +---+ +---+ > Alice ---| |--| |--- Bob > Alice ---|

[bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility

2020-05-25 Thread Chris Belcher via bitcoin-dev
=== Abstract === Imagine a future where a user Alice has bitcoins and wants to send them with maximal privacy, so she creates a special kind of transaction. For anyone looking at the blockchain her transaction appears completely normal with her coins seemingly going from address A to address B.

Re: [bitcoin-dev] SAS: Succinct Atomic Swap

2020-05-12 Thread Chris Belcher via bitcoin-dev
Hello list, This proposal is very cool. It is very useful to have a coinswap scheme requiring only two transactions. As well as improving the scalability of the system by saving block space, it also improves privacy because the coins could stay unspend for a long time, potentially indefinitely.

Re: [bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients

2020-05-12 Thread Chris Belcher via bitcoin-dev
On 05/05/2020 16:16, Lloyd Fournier via bitcoin-dev wrote: > On Tue, May 5, 2020 at 9:01 PM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote: >>> Trust-minimization of Bitcoin security model has

Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

2020-05-03 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, >>> This "as long as the inputs that should be separate are not co-spent" is >>> precisely what mixdepths protect against, which is why I think some kind of >>> mixdepth facility will still matter in CoinSwap. >>> Still, you have convinced me that, for the purpose of

Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

2020-04-30 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 30/04/2020 09:54, ZmnSCPxj wrote: > Good morning CB, > > >> Equal-output-coinjoins and JoinMarket also have a version of the >> common-input-ownership-heuristic (CIOH), because its often possible to >> separate the inputs into sets of their owners of a equal-output-coinjoin

Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

2020-04-29 Thread Chris Belcher via bitcoin-dev
Hello ZmnSCPxj, On 29/04/2020 08:56, ZmnSCPxj wrote: > It wold be nice to interoperate with JoinMarket, i.e. have a JoinMarket maker > that also provides CoinSwap services using the same UTXOs. A great benefit of a CoinSwap system is that the transactions are steganographic. If

Re: [bitcoin-dev] Fwd: (Semi)Traceless 2-party coinjoin off-chain protocol using schnorr signatures

2020-04-28 Thread Chris Belcher via bitcoin-dev
On 24/04/2020 02:34, ZmnSCPxj via bitcoin-dev wrote: > Good morning Germán, > > >> With regards to trying to tackle the problem of value-based correlations, >> wouldn't it be possible to try to model the solution after the >> equal-sum-subset problem (np complete problem)( >>

[bitcoin-dev] Base64-encoded descriptors

2019-12-24 Thread Chris Belcher via bitcoin-dev
I've recently been playing around with descriptors, and they are very nice to work with. They should become the standard for master public keys IMO. One downside is that users cant easily copypaste them to-and-fro to make watch-only wallet. The descriptors contain parenthesis and commas which

Re: [bitcoin-dev] BIPable-idea: Consistent and better definition of the term 'address'

2019-10-09 Thread Chris Belcher via bitcoin-dev
This is an excellent idea and I hope something like this happens. I've had the idea of using an intermediate name to make the transition easier, for example "Bitcoin address" becomes "Bitcoin invoice address" which after 10 years becomes "Bitcoin invoice" (or "Bitcoin invoice"). "Invoice" would

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

2019-08-08 Thread Chris Belcher via bitcoin-dev
Hello list, Two points: * The V^2 term is the only thing in the whole scheme that provides any sybil protection. I've already gone through the reasoning in an earlier email and the maths is clear; in a scheme with linear V honest makers have no economic advantage over sybil attackers. This is

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

2019-08-07 Thread Chris Belcher via bitcoin-dev
These are very creative schemes. At the very least they would stop the easy mindless renting TXO method, where someone with coins on a hardware wallet simply creates a signature and copypastes it into a website to get free money. The workaround scheme with shared ownership of TXOs requires brand

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

2019-08-07 Thread Chris Belcher via bitcoin-dev
On 07/08/2019 00:33, ZmnSCPxj wrote: > Good morning all, > > It might be useful to remember that there exists pressure to pool > proof-of-work due to tiny non-linearities caused by Proximity Premium and > Variance Discount flaws. > Similarly, any non-linearity in any fidelity bond scheme exerts

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

2019-08-06 Thread Chris Belcher via bitcoin-dev
On 06/08/2019 02:51, Leo Wandersleb via bitcoin-dev wrote: > On 8/6/19 7:04 AM, Chris Belcher via bitcoin-dev wrote: >> However, there _is_ a cost to being a sybil attacker. If we define >> honest makers as entities who run just one maker bot, and dishonest >> makers as enti

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

2019-08-05 Thread Chris Belcher via bitcoin-dev
On 02/08/2019 10:50, Dmitry Petukhov wrote: > В Fri, 2 Aug 2019 10:21:57 +0100 > Chris Belcher wrote: > >> The aim of the fidelity bond scheme is to require makers >> to sacrifice value, renting out their fidelity bond coins doesn't >> avoid that sacrifice because the sacrifice is the paid rent

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

2019-08-02 Thread Chris Belcher via bitcoin-dev
On 31/07/2019 16:50, Dmitry Petukhov wrote: > В Tue, 30 Jul 2019 22:39:14 +0100 > Chris Belcher via bitcoin-dev > wrote: > >> This is where a sacrifice of V bitcoins creates a >> bond of value V^2. The formula provides a strong incentive for >> profit-motivated ma

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

2019-07-31 Thread Chris Belcher via bitcoin-dev
On 26/07/2019 10:38, Dmitry Petukhov via bitcoin-dev wrote: > > If the attacker is the entity who provides this 'maker outsourcing', > and it captures significant portion of that maker-outsourcing/utxo-rent > market, it can even receive some profit from the convenience fee, while >

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

2019-07-31 Thread Chris Belcher via bitcoin-dev
On 27/07/2019 20:34, David A. Harding wrote: > > Timelocking bitcoins, especially for long periods, carries some special > risks in Bitcoin: > > 1. Inability to sell fork coins, also creating an inability to influence > the price signals that help determine the outcome of chainsplits. > > 2.

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

2019-07-25 Thread Chris Belcher via bitcoin-dev
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

[bitcoin-dev] Privacy literature review

2019-03-05 Thread Chris Belcher via bitcoin-dev
Hello list, For the last few weeks I've been working on a literature review for bitcoin privacy: https://en.bitcoin.it/wiki/Privacy It aims to cover about all privacy issues in bitcoin, including Lightning network, and has a bunch of examples to help demonstrate how the concepts work in

Re: [bitcoin-dev] Transaction Input/Output Sorting

2018-10-24 Thread Chris Belcher via bitcoin-dev
Thanks for bringing our attention to this important topic. According to (https://p2sh.info/dashboard/db/bip-69-stats) around 60% of transaction follow bip69 (possibly just by chance). If its useful, a bitcoin wiki page that tracks wallets which use bip69 can be created. A similar page exists for

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

2018-05-10 Thread Chris Belcher via bitcoin-dev
Thanks for the summary, It may be worth emphasizing the fungibility aspects of all this. That summary contains ideas to possibly have separate address types, opcodes and scriptSigs/witnesses for different feature, at least to start with. To me this would seem bad because it may miss out on the

[bitcoin-dev] Electrum Personal Server beta release

2018-03-29 Thread Chris Belcher via bitcoin-dev
Electrum Personal Server is an implementation of the Electrum wallet server protocol that allows users to point their Electrum wallet at their own full node. It is compatible resource-saving features like pruning, blocksonly and disabled txindex. It is much less resource-intensive than other

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

2018-01-22 Thread Chris Belcher via bitcoin-dev
This sounds like a useful idea for improving the privacy of coinswap. Traditionally coinswap mixing had an anonymity set related to the number of multisig transactions being used on the blockchain. With the new tech of Schnorr, MAST and now this Taproot, with sufficient adoption coinswap's

[bitcoin-dev] Payment Channel Payouts: An Idea for Improving P2Pool Scalability

2017-08-30 Thread Chris Belcher via bitcoin-dev
Pooled mining in bitcoin contributes to miner centralization. P2Pool is one solution but has bad scalability; additional hashers require the coinbase transaction to be larger, bigger miners joining increase the variance of payouts for everyone else, and smaller miners must pay extra to consolidate

Re: [bitcoin-dev] Moving towards user activated soft fork activation

2017-03-05 Thread Chris Belcher via bitcoin-dev
I think UASF is a great idea for the reasons mentioned before that it more closely matches the balance of powers in bitcoin, and that its much more opt-in. Many people are comparing an UASF fork with a hard fork. I disagree with this view and I think there is a difference between the two kinds of

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

2017-02-16 Thread Chris Belcher via bitcoin-dev
I believe this proposal still suffers from one problem that bip37 did, albiet by a much lesser extent. Combining the partial information from the block downloads with the transaction subgraph information from the blockchain can in some cases still reveal which addresses belong to the wallet.

Re: [bitcoin-dev] Start time for BIP141 (segwit)

2016-10-16 Thread Chris Belcher via bitcoin-dev
Hello, Excellent news that segregated witness is nearing release for the mainnet. I know I don't only speak for myself in saying that this has been eagerly awaited for some time. For the timing, I'd support segwit being usable on the network as soon as is technically and safely possible. We at

[bitcoin-dev] Clearing up some misconceptions about full nodes

2016-02-10 Thread Chris Belcher via bitcoin-dev
I've been asked to post this to this mailing list too. It's time to clear up some misconceptions floating around about full nodes. === Myth: There are only about 5500 full nodes worldwide === This number comes from this and similar sites: https://bitnodes.21.co/ and it measured by trying to