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 be
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 has
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
(proba
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 notic
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 pa
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_ applicati
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 fide
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 h
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 their
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 28/06/20
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
Statu
what actually protected users, 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
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 soft
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 essential
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 01/03/202
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 in
for you (probably
> using a output descriptor you created to share with me).
>
> Sorry for the long semi-random rant.
>
> El vie, 15 ene 2021 a las 21:07, Chris Belcher via bitcoin-dev (<
> bitcoin-dev@lists.linuxfoundation.org>) escribió:
>
>> PayJoin is an exci
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 Wal
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 impl
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)
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
onchain to protect
> against this kind of pinning scenario. 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 c
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 is
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 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 just
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 not
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 a
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 ca
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 lo
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 rec
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, i
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
>> easy
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 (A
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 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 ---| |
=== 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. Bu
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. W
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 a
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 multi-transa
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,
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 equal-output-coi
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)(
>> https://www.cs.mc
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
stop
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 a
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 bec
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 ne
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
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
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
>
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 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
> deanonymizin
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. Pos
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 d
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 practice
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
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
fu
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 Electr
Electrum is a popular bitcoin wallet, but it is not a full node wallet
as it synchronizes itself using third-party Electrum servers. The
servers must be trusted to verify the rules of bitcoin, they can trick
Electrum wallets into accepting fake bitcoin transactions which, for
example, print infinit
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 anonymit
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
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
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. Noneth
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'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 probe
64 matches
Mail list logo