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
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
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.
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
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
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
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
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
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
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
For the last few weeks I've been working on a literature review for
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
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
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.
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
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
On 31/07/2019 16:50, Dmitry Petukhov wrote:
> В Tue, 30 Jul 2019 22:39:14 +0100
> Chris Belcher via bitcoin-dev
>> 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
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
* 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
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
JoinMarket 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.
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").
I've recently been playing around with descriptors, and they are very
nice to work with. They should become the standard for master public
One downside is that users cant easily copypaste them to-and-fro to make
watch-only wallet. The descriptors contain parenthesis and commas which
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)(
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
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
>>> 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
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 <
> email@example.com> wrote:
>> On Tuesday 05 May 2020 10:17:37 Antoine Riard via bitcoin-dev wrote:
>>> Trust-minimization of Bitcoin security model has
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.
=== 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.
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
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.
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
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,
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
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
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
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.
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:
>> For CoinSwap as well, we
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
> These transactions:
> +---+ +---+
> Alice ---| |--| |--- Bob
> Alice ---|
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
> Let me know if I reviewed the correct transactions circuit model or
> misunderstood a
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
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
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
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.
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)
Mail list logo