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
wallet.
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
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
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
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
coinswap's
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
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
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.
>
> 2.
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
requires brand
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
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
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
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[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
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
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
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)(
>>
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
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
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
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.
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.
>
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)
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
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
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
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
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
=== 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.
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
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
>>
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,
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
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
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.
>>
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
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 ---|
PayJoin is an exciting bitcoin privacy technology which has the
potential to damage the ability of blockchain surveillance to spy on
bitcoin users and destroy bitcoin's fungibility. A protocol standard has
already been defined and implemented by a couple of projects such as
BTCPayServer, Wasabi
See
https://gist.github.com/chris-belcher/903feab321bf41055c91eaec46581e89
for the latest version of this BIP.
BIP: TBD
Layer: Applications
Title: Anti-fee-sniping protection with nSequence in taproot
transactions to improve privacy for off-chain protocols
Author: Chris Belcher
Good thinking. Your point also applies to CoinJoins (both equal-output
and payjoin), and to any transaction where multiple parties contribute
inputs.
The BIP should say "at least one of the inputs of the transaction" with
a suggestion that on-chain wallets just randomly pick an input.
On
It is wrong to say that using miner signalling alone for activation
(LOT=false) is a bug.
As we vividly saw in the events of the 2017 UASF, the purpose of miner
signalling isn't to activate or enforce the new rules but to stop a
chain split. A majority of miners can stop a chain split by
rs, miner protection is nothing something to
count on.
On 03/03/2021 17:30, yanma...@cock.li wrote:
> On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
>> Enter flag day activation. With a flag day there can be no
>> brinksmanship. A social media blitz cant do anything except
The idea of a fully-transparent bitcoin is dead and has been for many
years. This is because of various privacy tech such as CoinJoin,
Lightning Network, PayJoin, change avoidance, avoiding address reuse,
etc, along with a few new ones like CoinSwap and WabiSabi hopefully
coming soon.
On
The bitcoin world is close to total gridlock on the question of how to
activate taproot. There's no agreement on activation[1][2], and if an
agreement isn't reached then nothing happens. That would be really
terrible because we'd miss out on the benefits of taproot and
potentially other future
Suppose 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 bitcoin address A to address B. But in reality her
coins end up
Hello list,
Someone reviewing my taproot privacy BIP proposal suggested
clarification on the spec, so I've written some python-like pseudocode.
It implements the suggestion of choosing a random input instead of the
first one.
Some wallet teams are already working on implementing taproot for
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. But
in reality
Hello ZmnSCPxj,
You say "A taker can be a surveillor as well", as though that's simple
and easy to achieve. In reality there are many defenses against that.
Defending against the attack of a malicious taker aborting at the last
step is the purpose of the podle commitments which joinmarket
Hello list,
Fidelity bonds could be used to help create trust-minimized federations
that are needed for things like chaumian ecash servers or sidechains.
From what I've seen until now, people working on chaumian ecash or
sidechains say that the federation controlling the multisig keys will
Hello waxwing,
> A user sacrifices X amount of time-value-of-money (henceforth TVOM)
by committing in Joinmarket with FB1. He then uses the same FB1 in
Teleport, let's say. If he gets benefit Y from using FB1 in Joinmarket,
and benefit Z in Teleport, then presumably he'll only do it if
Hello ZmnSCPxj,
Renting out fidelity bonds is an interesting idea. It might happen in
the situation where a hodler wants to generate yield but doesn't want
the hassle of running a full node and yield generator. A big downside of
it is that the yield generator income is random while the rent
See
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e
for the latest version of this BIP.
BIP: TBD. Preferably a two-digit number to match the bip44, bip49,
bip84, bip86 family of bips
Layer: Applications
Title: Derivation scheme for storing timelocked address
Hello ZmnSCPxj,
This is an intended feature. I'm thinking that the same fidelity bond
can be used to running a JoinMarket maker as well as a Teleport
(Coinswap) maker.
I don't believe it's abusable. It would be a problem if the same
fidelity bond is used by two makers in the _same_
Hello ZmnSCPxj,
Such a system will have to be publicly advertised, in the same way we
see centralized cryptocurrency staking shops buying ads all over the
place. That's how they'll make retail hodlers aware that renting out
your coins in this way is possible. If JoinMarket/Teleport users
60 matches
Mail list logo
