Nostr notes by

📅 Original date posted:2020-05-12 📝 Original message: On ...

2023-06-09T13:00:07Z

In reply to nevent1q…9nn6
_________________________

📅 Original date posted:2020-05-12
📝 Original message:
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 at 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 always relied first and
>>> above on running a full-node. This current paradigm may be shifted by LN
>>> where fast, affordable, confidential, censorship-resistant payment
>> services
>>> may attract a lot of adoption without users running a full-node.
>>
>> No, it cannot be shifted. This would compromise Bitcoin itself, which for
>> security depends on the assumption that a supermajority of the economy is
>> verifying their incoming transactions using their own full node.
>>
>
> Hi Luke,
>
> I have heard this claim made several times but have never understood the
> argument behind it. The question I always have is: If I get scammed by not
> verifying my incoming transactions properly how can this affect anyone
> else? It's very unintuative. I've been scammed several times in my life in
> fiat currency transactions but as far as I could tell it never negatively
> affected the currency overall!
>
> The links you point and from what I've seen you say before refer to "miner
> control" as the culprit. My only thought is that this is because a light
> client could follow a dishonest majority of hash power chain. But this just
> brings me back to the question. If, instead of BTC, I get a payment in some
> miner scamcoin on their dishonest fork (but I think it's BTC because I'm
> running a light client) that still seems to only to damage me. Where does
> the side effect onto others on the network come from?
>
> Cheers,
>
> LL
>

Hello Lloyd,

The problem comes when a large part of the ecosystem gets scammed at
once, which is how such an attack would happen in practice.

For example, consider if bitcoin had 10000 users. 10 of them use a full
node wallet while the other 9990 use an SPV wallet. If a miner attacked
the system by printing infinite bitcoins and spending coins without a
valid signature, then the 9990 SPV wallets would accept those fake coins
as payment, and trade the coins amongst themselves. After a time those
coins would likely be the ancestors of most active coins in the
9990-SPV-wallet ecosystem. Bitcoin would split into two currencies:
full-node-coin and SPV-coin.

Now the fraud miners may become well known, perhaps being published on
bitcoin news portals, but the 9990-SPV-wallet ecosystem has a strong
incentive to be against any rollback. Their recent transactions would
disappear and they'd lose money. They would argue that they've already
been using the coin for a while, and it works perfectly fine, and anyway
a coin that can be spent in 9990 places is more useful than one that can
be spent in just 10 places. The SPV-wallet community might even decide
to use something like `invalidateblock` to make sure their SPV-coin
doesn't get reorg'd out of existence. There'd also likely be a social
attack, with every bitcoin community portal being flooded with bots and
shills advocating the merits of SPV-coin. This is not a hypothetical
because we already saw the same thing during the scalability conflict
2015-2017.

Before you know it, "Bitcoin" would become SPV-coin with inflation and
arbitrary seizure. Any normal user could download software called
"Bitcoin wallet" which they trust and have used before, but instead of
using Bitcoin they'd be using SPV-coin. You may be one of the 10 wallets
backed by a full node, but that won't do much good to you when 9990
users happily use another coin as their medium of exchange.

Regards
CB

📅 Original date posted:2022-05-13 📝 Original message:Hello ...

2023-06-07T23:08:50Z

In reply to nevent1q…3t52
_________________________

📅 Original date posted:2022-05-13
📝 Original message: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
(probabilistically) he thinks Y+Z > X.

> But as an assessor of FB1 in Joinmarket, I don't know if it's also
being used for Teleport, and more importantly, if it's being used
somewhere else I'm not even aware of. Now I'm not an economist I admit,
so I might not be intuit-ing this situation right, but it fees to me
like the right answer is "It's fine for a closed system, but not an open
one." (i.e. if the set of possible usages is not something that all
participants have fixed in advance, then there is an effective Sybilling
problem, like I'm, as an assessor, thinking that sacrificed value 100 is
there, whereas actually it's only 15, or whatever.)

I don't entirely agree with this. The value of the sacrifice doesn't
change if the fidelity bond owner starts using it for Teleport as well
as Joinmarket. The sacrifice is still 100. Even if the owner doesn't run
any maker at all the sacrifice would still be 100, because it only
depends on the bitcoin value and locktime. In your equation Y+Z > X,
using a fidelity bond for more applications increases the
left-hand-side, while the right-hand-side X remains the same. As
protection from a sybil attack is calculated using only X, it makes no
difference what Y and Z are, the takers can still always calculate that
"to sybil attack the coinjoin I'm about to make, it costs A btc locked
up for B time".

Regarding fidelity bonds being used for both, I expect that most
fidelity bond owners will use their bonds with both Joinmarket and
Teleport, to not do that is just leaving money on the table.

If an attacker locks up the 100k btc or whatever the requirement is now,
and actually does a successful sybil attack against Joinmarket, then
they could at the same time do a successful sybil attack against
teleport with little added cost. So both markets form a single fidelity
bond ecosystem. This is a similar situation to merge-mining bitcoin with
an altcoin that also uses SHA256^2 for proof of work. The two or more
coins form one mining ecosystem. This results in the users of the small
altcoin benefiting from having their transactions protected by bitcoin's
massive hashrate. In this analogy the new small Teleport system can very
quickly benefit from the large amount of fidelity bonds already used in
Joinmarket.

Yes the hypothetical attacker can attack all systems at once, but the
defenders can defend all systems at once (and we can say not just that
they "can" do it, but that they "will" do it, or else they leave money
on the table). The mathematics which gives a huge advantage to the
defender still applies.

----

You've convinced me that specifying the exact form of the fidelity bond
certificate is a bad idea. I'll leave it more general, saying just that
wallets should be able to do SignMessage using the timelocked privkey.
And I'll leave the example signature in the test vectors.

I've made edits to this effect on the gist:
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e/revisions#diff-4f1f364f340b78bdfe9dca2ff50784bd312d49be220e5e5c2e4675447f79c6e8

It's worth noting that even if the certificate message is different
across the two systems, a fidelity bond owner can still create two
signatures over two different messages (e.g.
"fidelity-bond-cert|<pubkey>|<expiry>" and
"fidelity-bond-cert-teleport|<pubkey>|<expiry>").

📅 Original date posted:2022-05-03 📝 Original message:Hello ...

2023-06-07T23:08:46Z

In reply to nevent1q…cpv0
_________________________

📅 Original date posted:2022-05-03
📝 Original message: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 notice
such ads appearing then we could change the taker code to remove the
intermediate certificate keypair, and have the fidelity bond UTXO key
sign the endpoint (IRC nickname or onion hostname) directly. This
removes the possibility of fidelity bonds in cold storage. It would have
to be done for privacy, and it wouldn't be too bad. Right now there's no
cold storage solution for fidelity bonds yet JoinMarket has about 600
bitcoins locked up and advertised, which must be all on hot wallets.

Best,
CB

On 03/05/2022 06:26, ZmnSCPxj wrote:
> Good morning Chris,
>
>> 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 paid is a
>> fixed cost, so there's a chance that the income won't cover the rent.
>
> The fact that *renting* is at all possible suggests to me that the following situation *could* arise:
>
> * A market of lessors arises.
> * A surveillor creates multiple identities.
> * Each fake identity rents separately from multiple lessors.
> * Surveillor gets privacy data by paying out rent money to the lessor market.
>
> In defiads, I and Tamas pretty much concluded that rental would happen inevitably.
> One could say that defiads was a kind of fidelity bond system.
> Our solution for defiads was to prioritize propagating advertisements (roughly equivalent to the certificates in your system, I think) with larger bonded values * min(bonded_time, 1 year).
> However, do note that we did not intend defiads to be used for privacy-sensitive applications like JoinMarket/Teleport.
>
>
> Regards,
> ZmnSCPxj

📅 Original date posted:2022-05-01 📝 Original message:Hello ...

2023-06-07T23:08:45Z

In reply to nevent1q…47na
_________________________

📅 Original date posted:2022-05-01
📝 Original message: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_ application, but
JoinMarket takers are already coded to check for this, and Teleport
takers will soon as well. Using the same bond across different
applications is fine.

Best,
CB

On 01/05/2022 10:43, ZmnSCPxj wrote:
> Good morning Chris,
>
> Excellent BIP!
>
>>From a quick read-over, it seems to me that the fidelity bond does not commit to any particular scheme or application.
> This means (as I understand it) that the same fidelity bond can be used to prove existence across multiple applications.
> I am uncertain whether this is potentially abusable or not.
>
>
> Regards,
> ZmnSCPxj

📅 Original date posted:2022-05-02 📝 Original message:Hello ...

2023-06-07T23:08:45Z

In reply to nevent1q…u9fc
_________________________

📅 Original date posted:2022-05-02
📝 Original message: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 paid is a
fixed cost, so there's a chance that the income won't cover the rent.

JoinMarket takers since the start have checked that a fidelity bond
doesn't appear twice. The technique doesn't deserve a section in the BIP
because this BIP is only about specifying the wallets that hold fidelity
bond UTXOs for makers, not takers which receive fidelity bond messages.

In JoinMarket this is done in this code here:
https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/6b05f65260a487cd22f175ba64d499fbe8122530/jmclient/jmclient/taker.py#L1020-L1021

Best,
CB

On 01/05/2022 12:41, ZmnSCPxj wrote:
> Good morning again Chris,
>
> I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I am interested in application A, you are interested in application B, and you rent my fidelity bond for application B.
> We can use a pay-for-signature protocol now that Taproot is available, so that the signature for the certificate for your usage of application B can only be completed if I reveal a secret via a signature on another Taproot UTXO that gets me the rent for the fidelity bond.
>
> I do not know if this would count as "abuse" or just plain "economic sensibility".
> But a time may come where people just offer fidelity bonds for lease without actually caring about the actual applications it is being used *for*.
> If the point is simply to make it costly to show your existence, whether you pay for the fidelity bond by renting it, or by acquiring your own Bitcoins and foregoing the ability to utilize it for some amount of time (which should cost closely to renting the fidelity bond from a provider), should probably not matter economically.
>
> You mention that JoinMarket clients now check for fidelity bonds not being used across multiple makers, how is this done exactly, and does the technique not deserve a section in this BIP?
>
> Regards,
> ZmnSCPxj

📅 Original date posted:2022-05-01 📝 Original message:See ...

2023-06-07T23:08:44Z

In reply to nevent1q…m7mp
_________________________

📅 Original date posted:2022-05-01
📝 Original message:See
https://gist.github.com/chris-belcher/7257763cedcc014de2cd4239857cd36e
for the latest version of this BIP.

<pre>
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 fidelity
bonds in BIP39 phrases
Author: Chris Belcher <belcher at riseup dot net>
Status: Draft
Type: Standards Track
Comments-Summary: No comments yet.
Created: 2022-04-01
License: CC0-1.0
</pre>

== Abstract ==

This BIP defines the derivation scheme for BIP39 seed phrases which
create timelocked addresses used for creating fidelity bonds. It also
defines how to sign fidelity bond certificates, which are needed when
using fidelity bonds that are stored offline.

== Motivation ==

Fidelity bonds are used to resist sybil attacks in certain decentralized
anonymous protocols. They are created by locking up bitcoins using the
`OP_CHECKLOCKTIMEVERIFY` opcode.

It would be useful to have a common derivation scheme so that users of
wallet software can have a backup of their fidelity bonds by storing
only the BIP39 seed phrase and a reference to this BIP. Importantly the
user does not need to backup any timelock values.

We largely use the same approach used in BIPs 49, 84 and 86 for ease of
implementation.

This standard is already implemented and deployed in JoinMarket. As most
changes would requires a protocol change of a live system, there is
limited scope for changing this standard in review. This BIP is more
about documenting something which already exists, warts and all.

== Background ==

=== Fidelity bonds ===

A fidelity bond is a mechanism where bitcoin value is deliberately
sacrificed to make a cryptographic identity expensive to obtain. A way
to create a fidelity bond is to lock up bitcoins by sending them to a
timelocked address. The valuable thing being sacrificed is the
time-value-of-money.

The sacrifice must be done in a way that can be proven to a third party.
This proof can be made by showing the UTXO outpoint, the address
redeemscript and a signature which signs a message using the private key
corresponding to the public key in the redeemscript.

The sacrificed value is an objective measurement that can't be faked and
which can be verified by anybody (just like, for example PoW mining).
Sybil attacks can be made very expensive by forcing a hypothetical sybil
attacker to lock up many bitcoins for a long time. JoinMarket implements
fidelity bonds for protection from sybil attackers. At the time of
writing over 600 BTC in total have been locked up with some for many
years. Their UTXOs and signatures have been advertised to the world as
proof. We can calculate that for a sybil attacker to succeed in unmixing
all the CoinJoins, they would have to lock up over 100k BTC for several
years.

=== Fidelity bonds in cold storage ===

It would be useful to be able to keep the private keys of timelocked
addresses in cold storage. This would allow the sybil resistance of a
system to increase without hot wallet risk. For this reason there is an
intermediate keypair called the certificate.

UTXO key ---signs---> certificate ---signs---> endpoint (e.g. IRC
nickname or tor .onion hostname)

The certificate keypair can be kept online and used to prove ownership
of the fidelity bond. Even if the hot wallet private keys are stolen,
the coins in the timelocked address will still be safe, although the
thief will be able to impersonate the fidelity bond until the expiry.

=== Fixed timelock values ===

It would be useful for the user to avoid having to keep a record of the
timelocks in the time-locked addresses. So only a limited small set of
timelocks are defined by this BIP. This way the user must only store
their seed phrase, and knowledge that they have coins stored using this
BIP standard. The user doesn't need to remember or store any dates.

== Specifications ==

This BIP defines the two needed steps to derive multiple deterministic
addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key.
It also defines the format of the certificate can be signed by the
deterministic address key.

=== Public key derivation ===

To derive a public key from the root account, this BIP uses a similar
account-structure as defined in BIP [[bip-0084.mediawiki|44]] but with
<tt>change</tt> set to <tt>2</tt>.

<pre>
m / 84' / 0' / 0' / 2 / index
</pre>

A key derived with this derivation path pattern will be referred to as
<tt>derived_key</tt> further
in this document.

For <tt>index</tt>, addresses are numbered from 0 in a sequentially
increasing manner, but index does not increase forever like in other
similar standards. The index only goes up to <tt>959</tt> inclusive.
Only 960 addresses can be derived for a given BIP32 master key.
Furthermore there is no concept of a gap limit, instead wallets must
always generate all 960 addresses and check all of them if they have a
balance and history.

=== Timelock derivation ===

The timelock used in the time-locked address is derived from the
<tt>index</tt>. The timelock is a unix time. It is always the first of
the month at midnight. The <tt>index</tt> counts upwards the months from
January 2020, ending in December 2099. At 12 months per year for 80
years this totals 960 timelocks. Note that care must be taken with the
year 2038 problem on 32-bit systems.

<pre>
year = 2020 + index // 12
month = 1 + index % 12
</pre>

=== Address derivation ===

To derive the address from the above calculated public key and timelock,
we create a <tt>redeemScript</tt> which locks the funds until the
<tt>timelock</tt>, and then checks the signature of the
<tt>derived_key</tt>. The <tt>redeemScript</tt> is hashed with SHA256 to
produce a 32-byte hash value that forms the <tt>scriptPubKey</tt> of the
P2WSH address.

redeemScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP
<derived_key> OP_CHECKSIG
witness: <signature> <pubkey>
scriptSig: (empty)
scriptPubKey: 0 <32-byte-hash>
(0x0020{32-byte-hash})

=== Certificate message derivation ===

To create a certificate needed for using fidelity bonds in cold storage,
another application external to this standard will create a ECDSA
keypair. The public key of this keypair and an integer called the
`expiry` will be used to create a certificate message.

The certificate message is defined as:

'fidelity-bond-cert|' + cert_pubkey + '|' + cert_expiry

where + denotes concatenation. `cert_pubkey` is encoded as a hex string,
and `cert_expiry` is encoded as an ascii string of the integer.

This certificate message is then prepended with the string `\x18Bitcoin
Signed Message:\n` and a byte denoting the length of the certificate
message. The whole thing is then signed with the private key of the
<tt>derived_key</tt>. This part is identical to the "Sign Message"
function which many wallets already implement.

Almost all wallets implementing this standard can use their
already-existing "Sign Message" function to sign the certificate
message. As the certificate message itself is always an ascii string,
the wallet may not need to specially implement this section at all but
just rely on users copypasting their certificate message into the
already-existing "Sign Message" user interface. This works as long as
the wallet knows how to use the private key of the timelocked address
for signing messages.

It is most important for wallet implementions of this standard to
support creating the certificate signature. Verifying the certificate
signature is less important.

== Test vectors ==

<pre>
mnemonic = abandon abandon abandon abandon abandon abandon abandon
abandon abandon abandon abandon about
rootpriv =
xprv9s21ZrQH143K3GJpoapnV8SFfukcVBSfeCficPSGfubmSFDxo1kuHnLisriDvSnRRuL2Qrg5ggqHKNVpxR86QEC8w35uxmGoggxtQTPvfUu
rootpub =
xpub661MyMwAqRbcFkPHucMnrGNzDwb6teAX1RbKQmqtEF8kK3Z7LZ59qafCjB9eCRLiTVG3uxBxgKvRgbubRhqSKXnGGb1aoaqLrpMBDrVxga8

// First timelocked address = m/84'/0'/0'/2/0
derived private_key = L2tQBEdhC48YLeEWNg3e4msk94iKfyVa9hdfzRwUERabZ53TfH3d
derived public_key =
02a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011
unix locktime = 1577836800
string locktime = 2020-01-01 00:00:00
redeemscript =
0400e10b5eb1752102a1b09f93073c63f205086440898141c0c3c6d24f69a18db608224bcf143fa011ac
scriptPubKey =
0020bdee9515359fc9df912318523b4cd22f1c0b5410232dc943be73f9f4f07e39ad
address =
bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84

// Test certificate using first timelocked address
// Note that as signatures contains a random nonce, it might not be
exactly the same when your code generates it
// p2pkh address is the p2pkh address corresponding to the derived
public key, it can be used to verify the message
// signature in any wallet that supports Verify Message.
// As mentioned before, it is more important for implementors of this
standard to support signing such messages, not verifying them
Message =
fidelity-bond-cert|020000000000000000000000000000000000000000000000000000000000000001|375
Address =
bc1qhhhf29f4nlyalyfrrpfrknxj9uwqk4qsyvkujsa7w0ulfur78xkspsqn84
p2pkh address = 16vmiGpY1rEaYnpGgtG7FZgr2uFCpeDgV6
Signature =
H2b/90XcKnIU/D1nSCPhk8OcxrHebMCr4Ok2d2yDnbKDTSThNsNKA64CT4v2kt+xA1JmGRG/dMnUUH1kKqCVSHo=

// 2nd timelocked address = m/84'/0'/0'/2/1
derived private_key = KxctaFBzetyc9KXeUr6jxESCZiCEXRuwnQMw7h7hroP6MqnWN6Pf
derived public_key =
02599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002d
unix locktime = 1580515200
string locktime = 2020-02-01 00:00:00
redeemscript =
0480bf345eb1752102599f6db8b33265a44200fef0be79c927398ed0b46c6a82fa6ddaa5be2714002dac
scriptPubKey =
0020b8f898643991608524ed04e0c6779f632a57f1ffa3a3a306cd81432c5533e9ae
address =
bc1qhrufsepej9sg2f8dqnsvvaulvv490u0l5w36xpkds9pjc4fnaxhq7pcm4h

// timelocked address after the year 2038 problem = m/84'/0'/0'/2/240
derived private_key = L3SYqae23ZoDDcyEA8rRBK83h1MDqxaDG57imMc9FUx1J8o9anQe
derived public_key =
03ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226
unix locktime = 2208988800
string locktime = 2040-01-01 00:00:00
redeemscript =
05807eaa8300b1752103ec8067418537bbb52d5d3e64e2868e67635c33cfeadeb9a46199f89ebfaab226ac
scriptPubKey =
0020e7de0ad2720ae1d6cc9b6ad91af57eb74646762cf594c91c18f6d5e7a873635a
address =
bc1qul0q45njptsadnymdtv34at7karyva3v7k2vj8qc7m2702rnvddq0z20u5

// last timelocked address = m/84'/0'/0'/2/959
derived private_key = L5Z9DDMnj5RZMyyPiQLCvN48Xt7GGmev6cjvJXD8uz5EqiY8trNJ
derived public_key =
0308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3
unix locktime = 4099766400
string locktime = 2099-12-01 00:00:00
redeemscript =
0580785df400b175210308c5751121b1ae5c973cdc7071312f6fc10ab864262f0cbd8134f056166e50f3ac
scriptPubKey =
0020803268e042008737cf439748cbb5a4449e311da9aa64ae3ac56d84d059654f85
address =
bc1qsqex3czzqzrn0n6rjayvhddygj0rz8df4fj2uwk9dkzdqkt9f7zs5c493u
</pre>

Code generating these test vectors can be found here:
https://github.com/chris-belcher/timelocked-addresses-fidelity-bond-bip-testvectors

==Reference==

*
[[https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af/|Design
for improving JoinMarket's resistance to sybil attacks using fidelity
bonds]]
*
[[https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/fidelity-bonds.md|JoinMarket
fidelity bonds doc page]]
* [[bip-0065.mediawiki|BIP86 - OP_CHECKLOCKTIMEVERIFY]]
* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic
Wallets]]
* [[bip-0049.mediawiki|BIP49 - Derivation scheme for
P2WPKH-nested-in-P2SH based accounts]]
* [[bip-0084.mediawiki|BIP84 - Derivation scheme for P2WPKH based accounts]]
* [[bip-0086.mediawiki|BIP86 - Key Derivation for Single Key P2TR Outputs]]

📅 Original date posted:2022-02-28 📝 Original ...

2023-06-07T23:05:00Z

In reply to nevent1q…wdz8
_________________________

📅 Original date posted:2022-02-28
📝 Original message: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 her coins end up in address Z which is entirely unconnected
to either A or B.

Now imagine another user, Carol, who isn't too bothered by privacy and
sends her bitcoin using a regular wallet which exists today. But because
Carol's transaction looks exactly the same as Alice's, anybody analyzing
the blockchain must now deal with the possibility that Carol's
transaction actually sent her coins to a totally unconnected address. So
Carol's privacy is improved even though she didn't change her behavior,
and perhaps had never even heard of this software.

In a world where advertisers, social media and other institutions want
to collect all of Alice's and Carol's data, such privacy improvement
would be incredibly valuable. If even a small percentage of transactions
were actually created by this software, anybody doing analysis on the
blockchain would always have a niggle in the back of their mind: "what
if this transaction I'm looking at was actually a CoinSwap? How would I
know? What if these coins have actually disappeared into the mist?". The
doubt and uncertainty added to every transaction would greatly boost the
fungibility of bitcoin and so make it a better form of money.

Over a year ago I wrote to this list[1] about how undetectable privacy
can be developed today by implementing CoinSwap. Today I release the
first alpha version of this software:

https://github.com/bitcoin-teleport/teleport-transactions/

The project is almost completely decentralized and available for all to
use for free (baring things like miner fees). So far it is only really
usable by developers and power-users to play around with. It doesnt have
all the necessary features yet, but from now on I'll be doing new
releases very often as soon as every new feature gets added. It is
possible to run it on mainnet, but only the brave will attempt that, and
only with small amounts. I've personally made many coinswaps on the
testnet and signet networks, and I'll be running market makers on signet
which will be available for anyone to create coinswaps with.

Right now it just uses 2of2 multisig for the coinswap addresses. Those
address types are rare on the blockchain so the coinswaps stand out a
fair amount (although protocols like lightning also use 2of2 multisig).
However the next really big task on my todo list is to use ECDSA-2p
which would make these multisig addresses look like regular single-sig
addresses, which are overwhelmingly common out there and so provide an
enormous anonymity set.

My aim is that the Teleport project will develop into a practical and
secure project on the bitcoin mainnet, usable either standalone as a
kind of bitcoin mixing app, or as a library that existing wallets will
implement allowing their users with the touch of a button to send
bitcoin coinswap transactions with much greater privacy than as possible
before.

I want to thank everyone who has supported me financially over the last
several months, without them this project simply would not have been
possible. If bitcoin privacy and coinswap is something you find
important, please consider supporting my work with a donation:
https://bitcoinprivacy.me/coinswap-donations

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017898.html

📅 Original date posted:2021-03-03 📝 Original message:It is ...

2023-06-07T18:29:56Z

In reply to nevent1q…rksj
_________________________

📅 Original date posted:2021-03-03
📝 Original message:It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain rules
enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote brinksmanship.

It is not correct to say that this will work because "nobody will
disobey Core". In reality it will work because basically everyone either
wants taproot or has no opinion about taproot.

Your argument depends heavily on the word "egregious". I've shown that
for harmful changes like censorship can be resisted by the bitcoin
community. Can you come up with an example of a bad change which won't
be resisted?

Here's another example of an easily-resisted change: A Core team that's
been compromised might do a flag-day UASF where transactions are only
confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
community could resist this by doing a counter-UASF where a transaction
paying just 1 sat/vbyte is required to be included in the first block
after the flay day.

What alternative do you suggest? If you advocate allowing miners to
activate soft forks then that still won't protect users. Because miners
won't save users in my above example of a 1000 sat/vbyte price floor, in
fact miners would see their income greatly increased if the soft fork
was successful. So in fact the ability to do a counter-UASF is always
what actually protected users, miner protection is nothing something to
count on.

On 03/03/2021 17:30, yanmaani at 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 have its own
>> followers fork away. Crucially, miner signalling cant be used to change
>> the activation date for nodes that didn't choose to and just passively
>> follow signalling. Changing the activation date requires all those users
>> to actually run different node software.
>
> Is that supposed to be a good thing? "We should do X because it'll work"
> doesn't prove X is actually good. These things can be evil, but they can
> also be legitimate opposition to a change. Taking away the power of a
> "social media blitz" is not guaranteed to be a good thing!
>
>> What if one day the Core developer team uses the flag
>> day method to do something bad? The bitcoin user
>> community who wants to resist this can create their own
>> counter-soft-fork full node. This forces a chain
>> split. The real bitcoin which most people follow will be
>> the chain without censorship.
>
> [edited for brevity]
>
> That will only work for really egregious changes. In practice, most
> people will trust Core on all other (non-egregious) decisions, because
> of the inertia inherent in disobeying them.
>
> What you suggest may be an efficient way to ram taproot through, but is
> it inherently good? Nothing is free. This seems like de-facto forcing
> people to go along with you, because you're convinced you're right. In
> this case, you are, but you'd be convinced you'd be right even if you
> weren't so.
>
> You're right in suggesting that it will work, but the reason why it will
> work is because nobody wants to disobey Core. It seems immoral to
> exploit this fact.
>
> At least you shouldn't hard-code it and require dissenters to fork away.
> I exhort you to consider making all this controversial stuff settings
> that can be changed by RPC command or command-line flag; set the default
> value sure, but requiring a fork to change it is, in my opinion,
> oppressive.
>
> (Also consider some compromise, such as ">95% miner support before flag
> day or >33% on flag day")
>
> Best wishes
> Yanmaani

📅 Original date posted:2021-03-03 📝 Original message:The ...

2023-06-07T18:29:53Z

In reply to nevent1q…2lh0
_________________________

📅 Original date posted:2021-03-03
📝 Original message: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 forks.

A major problem with BIP8 is that it would result to a situation where
different parts of the bitcoin ecosystem run different consensus rules.
Some people will run LOT=true and others LOT=false. Worst of all, it
becomes vulnerable to a twitter/reddit/social media blitz which could
attempt to move the date of miner activation around.

Twitter and reddit drama provide a perfect cover for social attacks on
bitcoin.

Forced signalling leads to brinksmanship. Where two or more sides
(backed up by social media drama) enter into a game of chicken with
deployed nodes. If one of them doesn't concede then we get a damaging
chain split. And the $1 trillion in value that the bitcoin network
protects is put at risk. From the point of view of a miner or big
exchange stuck in the middle, if they look at the ecosystem of twitter
and reddit (especially if you think about all the problems with bots and
sockpuppets) they have no idea which consensus rules they should
actually follow and exactly what date they take effect. Miners,
exchanges, merchants and the rest of the ecosystem exist to serve their
customers and users, and trouble happens when they don't know what their
customers really want. Social media attacks are not just a theoretical
concern; back during the block size drama, the bitcoin reddits were
targetted by bots, sockpuppets and brigading[3].

Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its own
followers fork away. Crucially, miner signalling cant be used to change
the activation date for nodes that didn't choose to and just passively
follow signalling. Changing the activation date requires all those users
to actually run different node software.

Flag day activation works simply: we choose a block height and after
that block height the new taproot rules become enforced.

Supporters of the permissionless, "users rule" approach of LOT=true
should be happy because it completely takes miners out of activation.

Supporters of the safe, conservative approach of LOT=false can be made
happy with a few ways of derisking:

* Getting mining pools, businesses and users to look at the code and ask
if they (a) think its either neutral or good for their business or use
case and (b) they believe others view it similarly and that the
consensus changes proposed have a good social consensus around them.

* Setting the flag day far in the future (18 months or 2 years in the
original proposal[3]).

== What if flag day activation is used maliciously? ==

What if one day the Core developer team is co-opted and uses the flag
day method to do something bad? For example, a soft fork where sending
to certain blacklisted addresses is not allowed. The bitcoin user
community who wants to resist this can create their own
counter-soft-fork full node, where the first block after the flag day
MUST pay to one of those addresses on the blacklist. This forces a chain
split between the censorship rules and the no-censorship rules, and its
pretty obvious that the real bitcoin which most people follow will be
the chain without censorship.

For example, if a group of users didn't agree with taproot then they
could create their own counter-flag-day-activation which requires that a
transaction is included that does an invalid-spend from a taproot output
in the first block after the flag day height.

This is always possible with any user activated soft fork. In BIP8
LOT=true it could be done by rejecting block headers with certain
version bits signalled.

== But it will take so long! ==

We seem to be at a deadlock now. This will take less time than any other
method, because other methods might never happen. BIP8 is dead and from
what I see there's no other credible plan.

We've already waited years for taproot. I remember listening to talks
about bitcoin from 2015 of people discussing Schnorr signatures. And
given how slow segwit and p2sh adoption were its pretty likely that
we'll waiting a while for taproot to be actually adopted.

== A social media blitz could still try to activate it early ==

The brinksmanship only works because miner signalling can make many
other nodes activate early, even if those other nodes didn't do
anything. There can't be a game of chicken that puts the bitcoin network
at risk.

If a group of people did adopt alternative node software which has a
shorter flag day, they actually have a risk of slow blocks. Because they
cant trick or force any other nodes to come along with them, they are
likely to only have a small economy and therefore would lose a lot of
hashrate. Imagine trading bitcoins for cash in person and instead of
waiting 10 minutes for a confirmation you have to wait 3 hours because
the blocks are slow.

Also, the argument for downloading and running a different software only
to speed up activation is pretty weak. Taproot would activate in ~18
months, so why are you so impatient that you need it in 6 months? And
risk slow blocks for you while doing so? The big difference with BIP148
the segwit UASF, is that people *had to* run some other software
otherwise they would get *no soft fork at all*.

== Without miner signalling how do we know the new rules are even
activated? ==

When did you see miners signalling their support for the inflation schedule?

Bitcoin's rules are enforced by wallets backed by full nodes. You'll
always know if your own full node is enforcing the new rules. The thing
that matters isnt miner signalling but your own full node, and the nodes
of those you trade with.

Flag day activation is quite similar to the way block reward halvenings
work. At and after block height 630000 miners are only allowed to create
6.25 BTC rather than 12.5 BTC. Everyone knows that if miners continued
to create 12.5 BTC or more they would be unable to sell or spend those
coins anywhere.

In 2017 when segwit was being activated people created a huge list of
various bitcoin companies, merchants and wallets:
https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
Looking at that list, you would know that if someone stole coins from a
segwit address they would be unable to deposit them in many exchanges
and merchants: Bitrefill, Bitstamp, Kraken, Localbitcoins, Paxful,
Vaultoro, HitBTC, etc.

Then what happened is only a month after S2X was beaten this guy moved
40000 BTC to a segwit address, confident about the power of the network
to protect his coins.
https://old.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_loaded_moved_his_40k_btc/

If there's ever any doubt about flag day activation we can always draw
up a similar list, although if there's broad consensus about it then
there's no reason why bitcoin businesses wouldn't upgrade to the latest
Core, like they did with every other previous soft fork.

== This gives the impression that Core developers control the protocol ==

This objection has a mirror image argument: BIP8 with LOT=false gives
the impression that miners control the protocol(!)

Eventually some group has to make a decision. We will ask the bitcoin
economy and users what they think of flag day activation. It's pretty
clear that nobody seriously objects to taproot, and as described above
if Core developers did something evil the community could resist it with
a counter-flag-day-activation.

== TL;DR ==

I believe flag day activation is the way forward. It should answer all
the objections and risks which make other methods too controversial.
Let's go ahead and bring taproot to bitcoin!

== References ==

[1] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
luke-jr posts saying LOT=false in his view reintroduces a bug, he
compares it to introducing an inflation bug and just hoping that miners
will not exploit it.

[2] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
This whole thread has many people disagreeing with LOT=true

[3] -
https://old.reddit.com/r/Bitcoin/comments/4biob5/research_into_instantaneous_vote_behavior_in/

https://old.reddit.com/r/Bitcoin/comments/3v04pd/can_we_please_have_a_civil_discussion_about/cxjnz1d/?context=1

https://old.reddit.com/r/Bitcoin/comments/41ykkt/members_trying_to_destroy_bitcoin_on_this_thread/cz6ccka/?context=3

[4] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018495.html
Matt Corallo's flag day activation proposal

📅 Original date posted:2021-03-02 📝 Original message:It is ...

2023-06-07T18:29:44Z

In reply to nevent1q…cu4q
_________________________

📅 Original date posted:2021-03-02
📝 Original message: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 essentially
doing a 51% attack. Such attacks have been known about since day one,
and even the whitepaper writes about them.

So they are not a bug but an inherent part of the way bitcoin works. If
fixing this issue was a simple as setting a consensus rule parameter
then bitcoin would have been invented decades earlier than it was.

And certainly miner signalling cannot be compared to an inflation bug.
The inflation rules are enforced by the economy using full nodes, but
chain splits or lack of them is enforced by miners. They are two
different parts of the bitcoin system. Back in 2010 there was an
inflation bug CVE-2010-5139 (the "Value overflow incident") which proves
my point. Even though miners created a block which printed 184 billion
bitcoins, the economy quickly adopted a patch which fixed the bug and
miners switched over to the correct chain which soon overtook the bugged
chain (there was a reorg of 53 blocks).

Also another point: in a hypothetical chain split it's true that the
LOT=false chain would be vulnerable to reorgs, but it's also true that
the LOT=true would suffer from slow blocks.

So for example, imagine trading bitcoin for cash in person, but instead
of waiting on average 10 minutes for a confirmation you have to wait 2
hours. Imagine depositing coins to an exchange which requires 3
confirmation, then instead of waiting ~30 minutes you have to actually
wait 6 hours. This is a significant degradation in usability. The
situation is a mirror image of how the LOT=false chain is vulnerable to
reorgs. Both chains suffer if a chain split happens which is why they
are pretty important to avoid. That's why its inaccurate to portray
LOT=true chain as safe with no downsides at all.

On 28/02/2021 19:33, Luke Dashjr via bitcoin-dev wrote:
> (Note: I am writing this as a general case against LOT=False, but using
> Taproot simply as an example softfork. Note that this is addressing
> activation under the assumption that the softfork is ethical and has
> sufficient community support. If those criteria have not been met, no
> activation should be deployed at all, of any type.)
>
> As we saw in 2017 with BIP 9, coordinating activation by miner signal alone,
> despite its potential benefits, also leaves open the door to a miner veto.
> This was never the intended behaviour, and a bug, which took a rushed
> deployment of BIP148 to address. LOT=False would reintroduce that same bug.
> It wouldn't be much different than adding back the inflation bug
> (CVE-2018-17144) and trusting miners not to exploit it.
>
> Some have tried to spin LOT=True as some kind of punishment for miners or
> reactive "counter-attack". Rather, it is simply a fallback to avoid
> regression on this and other bugs. "Flag day" activation is not fundamentally
> flawed or dangerous, just slow since everyone needs time to upgrade.
> BIP 8(LOT=True) combines the certainty of such a flag day, with the speed
> improvement of a MASF, so that softforks can be activated both reasonably
> quick and safely.
>
> In the normal path, and that which BIP8(True) best incentivises, miners will
> simply upgrade and signal, and activation can occur as soon as the economic
> majority is expected to have had time to upgrade. In the worst-case path, the
> behaviour of LOT=True is the least-harmful result: unambiguous activation and
> enforcement by the economy, with miners either deciding to make an
> anti-Taproot(eg) altcoin, or continue mining Bitcoin. Even if ALL the miners
> revolt against the softfork, the LOT=True nodes are simply faced with a
> choice to hardfork (replacing the miners with a PoW change) or concede - they
> do not risk vulnerability or loss.
>
> With LOT=False in the picture, however, things can get messy: some users will
> enforce Taproot(eg) (those running LOT=True), while others will not (those
> with LOT=False). Users with LOT=True will still get all the safety thereof,
> but those with LOT=False will (in the event of miners deciding to produce a
> chain split) face an unreliable chain, being replaced by the LOT=True chain
> every time it overtakes the LOT=False chain in work. For 2 weeks, users with
> LOT=False would not have a usable network. The only way to resolve this would
> be to upgrade to LOT=True or to produce a softfork that makes an activated
> chain invalid (thereby taking the anti-Taproot path). Even if nobody ran
> LOT=True (very unlikely), LOT=False would still fail because users would be
> faced with either accepting the loss of Taproot(eg), or re-deploying from
> scratch with LOT=True. It accomplishes nothing compared to just deploying
> LOT=True from the beginning. Furthermore, this process creates a lot of
> confusion for users ("Yep, I upgraded for Taproot(eg). Wait, you mean I have
> to do it AGAIN?"), and in some scenarios additional code may be needed to
> handle the subsequent upgrade cleanly.
>
> To make matters worse for LOT=False, giving miners a veto also creates an
> incentive to second-guess the decision to activate and/or hold the activation
> hostage. This is a direct result of the bug giving them a power they weren't
> intended to have. Even if we trust miners to act ethically, that does not
> justify sustaining the bug creating both a possibility and incentive to
> behave unethically.
>
> So in all possible scenarios, LOT=False puts users and the network at
> significant risk. In all possible scenarios, LOT=True minimises risk to
> everyone and has no risk to users running LOT=True.
>
> The overall risk is maximally reduced by LOT=True being the only deployed
> parameter, and any introduction of LOT=False only increases risk probability
> and severity.
>
> For all these reasons, I regret adding LOT as an option to BIP 8, and think it
> would be best to remove it entirely, with all deployments in the future
> behaving as LOT=True. I do also recognise that there is not yet consensus on
> this, and for that reason I have not taken action (nor intend to) to remove
> LOT from BIP 8. However, the fact remains that LOT=False should not be used,
> and it is best if every softfork is deployed with LOT=True.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2021-03-02 📝 Original message:The ...

2023-06-07T18:29:31Z

In reply to nevent1q…x5t4
_________________________

📅 Original date posted:2021-03-02
📝 Original message: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/2021 22:37, Eric Voskuil via bitcoin-dev wrote:
> To be clear, is this a NACK because Taproot reduces “transparency” (increases privacy) on the chain (“maintaining consensus” is obviously an argument against any protocol change, so that’s a red herring)?
>
> And is it your theory that only an “honest” (statute abiding) person should have privacy, and not against the state, and/or that mixers are sufficient privacy?
>
> Personally, I’m not moved by such an argument. What do you think is the value proposition of Bitcoin?
>
> e
>
>> On Mar 1, 2021, at 14:21, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>
>> Good Afternoon,
>>
>> I am going to take tough terms with much of your reply and do appreciate a courteous practice. Having previously made public disclosure of my affiliation with Jambler.io it seems sufficient to disclose my affiliation through the link in my email signature block.
>>
>> My concern is not increased privacy it is maintaining consensus values and the transparency of the blockchain wherein all transactions are published in an immutable record and that forbids the redaction of information by any obfuscation. A separate concern is the availability of a privacy suitable for cash should a Bitcoin user desire and especially without disturbing the existing consensus.
>>
>> The use of a Bitcoin Mixer is to enable standard equivalent privacy. As you may experience yourself, you do not allow people to follow you around looking in your purse, suppose you are dealing entirely with cash, and to see where and how much you fill it up, and where you spend. Nonetheless, for an honest person, their wallet is available for government audit as are their financial affairs. This is consistent with the existing operation of consensus.
>>
>> My full email signature block is a disclosure where I have some affiliation with the referenced website being that it carries at least some information that I have provided or that in some way I am associated perhaps only making use of their services. For example, I hardly make a profit from LinkedIn just my information is there. Also, I have made previous public disclosure of the affiliation. Bitcoin Mixer 2.0 is a partner mixer run by Jambler.io wherein I receive a service referral fee and am not in receipt of any part of the process transaction. The operation block diagram provided by Jambler.io is provided here and attached.
>> <ip.bitcointalk.org.png>
>>
>> [ip.bitcointalk.org.png]-Operation of Jambler.io partner mixer
>> https://ip.bitcointalk.org/?u=https%3A%2F%2Fjambler.io%2Fimages%2Fscheme-1.png&t=622&c=gTi7r1cfh-yynw
>> from this thread https://bitcointalk.org/index.php?topic=5267588
>>
>>
>> The installation script provided by Jambler.io that is the basis of my referral website is also publicly published,
>> https://github.com/jambler-io/bitcoin-mixer
>>
>> The disclosure for the partner program is available from Jambler.io however and is made prominently on my referral website. While it may seem lucrative at first I insist all partner profits are reportable on your personal income.
>> https://jambler.io/become-partner.php
>>
>> I am certainly better than confident that you appreciate the difference between an open and transparent blockchain and the ability of the user to not reveal details of the content of their wallet publicly.
>>
>> If further clarification is required may I suggest you pay a token and mix some Bitcoin wherein our discussion may then have some point of reference.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> and other projects
>>
>> earn.com/willtech
>> linkedin.com/in/damianwilliamson
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> From: Ariel Lorenzo-Luaces <arielluaces at gmail.com>
>> Sent: Monday, 1 March 2021 12:07 AM
>> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Taproot NACK
>>
>> Hello LORD HIS EXCELLENCY JAMES HRMH
>>
>> I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com
>>
>> At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your concerns may be more profit motivated? I can't tell since you failed to disclose your relationship with the mixer.
>>
>> Could you please clarify your association with the bitcoin mixer and moving forward could you please always do proper disclosure any time you're publically talking about bitcoin transaction privacy. It's only fair to do so as to not mislead people in an attempt to manipulate at worst and just a courteous practice at best.
>>
>> Cheers
>> Ariel Lorenzo-Luaces
>> On Feb 28, 2021, at 4:36 AM, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Good Evening,
>>
>> Thank-you for your advice @JeremyRubin on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a transaction is identifiable, the PayTo Address, and the amount all without any obfuscation.
>>
>> Lightning does not really provide obfuscation, it provides a result of a subset of transactions although the operation of the channel is observable to the parties.
>>
>> The reports I were reading concerning the supposed operation of Taproot published in a public media channel may have been speculation or misinformation nonetheless it is prudent to conditionally reply as you see that I have. It is important not to allow things to slip through the cracks. As you may believe may astute reviewers could make a full disclosure to this list it is not to be expected.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> and other projects
>>
>> earn.com/willtech
>> linkedin.com/in/damianwilliamson
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> From: Jeremy <jlrubin at mit.edu>
>> Sent: Sunday, 28 February 2021 3:14 AM
>> To: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Taproot NACK
>>
>> I have good news for you: Taproot does not enable monero-like privacy features any moreso than already exist in Bitcoin today. At its core, taproot is a way to make transactions with embedded smart contracts less expensive, done so in a manner that may marginally improve privacy dependent on user behavior (but not in the monero-like way you mention). For example, it makes it possible for lightning channels to look structurally similar to single key wallets, but it does nothing inherently to obfuscate the transaction graph as in monero.
>>
>> Such "monero-like" transaction graph obfuscation may already exist in Bitcoin via other techniques (coinjoin, payjoin, coinswap, lightning, etc) with or without Taproot, so the point is further moot.
>>
>> Do you have a source on your reporting?
>>
>> You may wish to rescind your nack.
>>
>>
>> --
>> @JeremyRubin
>>
>>
>> On Sat, Feb 27, 2021 at 5:46 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Good Afternoon,
>>
>> It has been reported that Taproot will enable some Monero like features including the ability to hide transactions.
>>
>> If that is the case I offer a full NACK and let me explain.
>>
>> A part of the benefit of using Bitcoin is its honesty. The full transaction is published on the blockchain. If that were to change so that transactions may be obfuscated from scrutiny then any government would have unlimited impetus to ban Bitcoin, and speculation has that is the reason India has been reported to have banned cryptocurrencies already.
>>
>> I am in support of the expanded use case of Bitcoin without harming the established robust fairness and equal equity offered. The core functionality of Bitcoin, its values, must remain unaltered.
>>
>> KING JAMES HRMH
>> Great British Empire
>>
>> Regards,
>> The Australian
>> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
>> of Hougun Manor & Glencoe & British Empire
>> MR. Damian A. James Williamson
>> Wills
>>
>> et al.
>>
>>
>> Willtech
>> www.willtech.com.au
>> www.go-overt.com
>> and other projects
>>
>> earn.com/willtech
>> linkedin.com/in/damianwilliamson
>>
>>
>> m. 0487135719
>> f. +61261470192
>>
>>
>> This email does not constitute a general advice. Please disregard this email if misdelivered.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> <ip.bitcointalk.org.png>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2020-09-03 📝 Original message:Hello ...

2023-06-07T18:26:40Z

In reply to nevent1q…3gdr
_________________________

📅 Original date posted:2020-09-03
📝 Original message: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.
> Relative locktimes *require* a contract transaction to kick off the relative locktime period.
> On the other hand, with Scriptless Script (which we know how to do with 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a contract transaction.
>
> With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one participant holds a completely-signed timelock transaction while the other participant holds a completely-signed pointlock transaction.
> This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition.
> There is no transaction that both participants hold in completely-signed form.
>
> This should remove most of the shenanigans possible, and makes the 30xRBF safe for any range of fees.
> I think.
>
> Since for each PTLC a participant holds only its "own" transaction, it is possible for a participant to define its range of fees for the RBF versions of the transaction it owns, without negotiation with the other participant.
> Since the fee involved is deducted from its own transaction, each participant can define this range of RBFed fees and impose it on the partial signatures it gets from the other participant.
>
> --
>
> Private key turnover is still useful even in an absolute-timelock world.
>
> If we need to bump up the block delta between links, it might be impractical to have the total delta of a multi-hop swap be too long at the taker.
>
> As a concrete example, suppose A is a taker who wants to route over makers B and C.
> However, B and C require a CLTV delta of 1 week.
>
> If A wants to route "directly" A->B->C->A, then if something bad happens, it could be looking at having its funds locked for two weeks.
>
> To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A.
> This limits its funding lockup to 1 week.
>
> Private key turnover is useful since as soon as the A->B->A swap completes, it can directly fund the A->C->A swap from the B-side funding transaction of the A->B->A swap.
>
> | A->B->A | A->C->A |
> : : :
> A -:->funding A&B--> B : :
> : : :
> B -:->funding A&B -----:--> funding A&C --> C :
> : : :
> : :C-> funding A&C ------:-> to-cold A -->
> : : :
>
> This increases the number of transactions by 1 per swap beyond the first, compared to a direct routing A->B->C->A, but this may be worth it for A if the timelocks involved are too big for A.
>
> With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is unable to reliably determine if it is the last hop in the route.
>
> Without private key turnover, A would have:
>
> **NO** private key turnover!
>
> | A->B->A | A->C->A |
> : : :
> A -:->funding A&B--> B : :
> : : :
> B -:->funding A&B -----:--> claim A -> funding A&C --> C :
> : : :
> : : C-> funding A&C ------:-> to-cold A -->
> : : :
>
> So if timelock-deltas are possibly-high (to reduce the probability of the MAD-HTLC argument, and other attacks, succeeding), takers might prefer to route by completing one swap first before starting the next one, and private key turnover is useful by reducing blockspace required by each hop.
>
> For reference, this is how it looks like with a single A->B->C->A swap with private key turnover:
>
> | A->B->C->A |
> : :
> A -:->funding A&B--> B :
> : :
> B -:->funding B&C -> C :
> : :
> C -:->funding A&C -----:-> to-cold A -->
> : :
>
> This is still smaller than in the A->B->A, A->C->A with private key turnover, by one funding tx per hop.
> However, A risks a much higher timelock (twice the timelock).
> Thus, A might prefer a lower timelock in exchange for paying for an additional transaction.
>
> Regards,
> ZmnSCPxj
>

Separating the timelock and hashlock cases into two separate
transactions is a nice way to solve many of these problems.

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) then
for sure the transaction was not a CoinSwap, and so the anonymity set of
the CoinSwap system would be far smaller For this reason I'm pretty
desperate to solve the vulnerability without losing the coins remaining
unspent indefinitely feature.

We need to solve the vulnerability you found, which I'll call the
riskless theft attempt problem. So what do you think of this solution:

== Building block 1: A, B and C having different contract txes ==

In the original proposal each CoinSwap peer has the same contract
transaction, and either side can broadcast it whenever they like. This
actually isn't necessary. We can have a contract transaction
fully-signed but only known to one peer, with a possibly-different
transaction transaction fully-signed and only known to the other peer.

Obviously for the CoinSwap to work both contract transactions must have
the same hash-time-locked contract, but they can differ in other ways.

== Building block 2: collateral payments ==

The riskless theft attempt problem happens because the previous owner of
the coins knows the fully-signed contract transaction and can broadcast
it at no cost to themselves. So to solve the problem we add a cost.

There is a 2of2 multisig made up of Bob's and Charlie's keys. The
associated contract transaction known to Bob must now also have one of
Bob's single-sig inputs. The outputs are such that some of the money
from Bob's input now ends up in the HTLC output. The result is that
after the CoinSwap if Bob broadcasts his contract transaction but fails
to take the money from the HTLC output, then Bob will have lost money.

I'm calling this idea collateral payments, by analogy with collateral
used for loans. A collateral is someone valuable a debtor puts on the
table, and if they don't repay the loan then they lose the collateral
(presumably the creditor sells it to repay the loan).

Here is a diagram of the contract transaction known to Bob:

multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
collateral(B) [J btc] (Bob) [J-K btc]

where:
I = CoinSwap amount
J = Value of Bob's collateral input
K = Value that Bob loses if he broadcasts his contract tx but doesnt
get the money
M~ = miner fee (random variable)

The value K is something that can be set by the protocol, and made high
enough so that doing a riskless theft attempt is not worth it. Probably
the value of K will be quite small because the odds of a riskless
payment attempt succeeding is very small (assuming the makers all use
multiple redundant watchtowers). Mostly likely K will be smaller than
M~, so if the collateral is lost to Bob then the miners will the ones to
gain, rather than Charlie.

The other contract transaction, known only to Charlie, does not contain
a collateral input or collateral value (K), because Charlie can't do a
riskless theft attempt to Bob.

If Bob ever spends his collateral input in another transaction, then his
contract transaction will become invalid. However Bob will only be
harming himself, so he'll never do this.

I think this might be a fruitful idea, and soon I'll modify my earlier
detailed design to include it, and see if it can be made to work with no
weird edge cases or attacks.

=== Appendix: Brief historical note about separate contract txes ===

Separating hash- and time-lock branches into different transactions as
in ZmnSCPxj's design is actually very similar to the way the original
2013 CoinSwap design worked:
https://bitcointalk.org/index.php?topic=321228.0

The timelock branch was a transaction locked with nLockTime. And the
hashlock branch is another transaction spending to an output requiring
Carol's public key + hash preimage.

However Adam Gibson in 2017 found a vulnerability to this:
https://github.com/AdamISZ/CoinSwapCS/blob/master/docs/coinswap_tweak.md

The vulnerability is that even though Carol doesn't know the hash
preimage, she can still broadcast the hashlock transaction, which sends
the coins _into_ the hashlock contract, and that invalidates Alice's
timelock transaction. Carol is the only one who can spend the coins but
she doesn't know the hash preimage. The protocol then degenerates to the
MAD (mutually assured destruction) case because the coins are locked
forever.

Adam Gibson's fix was to include the hashlock and timelock branches into
the same transaction known to both peers, which is exactly the design I
used and for which all these vulnerabilities were found.

I realize now there is another way to solve the vulnerability, which is
to include a (Alice pubkey + OP_CLTV timelock) in Carol's contract
transaction. This means that if Carol broadcasts her contract tx (called
TX_2 in the text) without knowing the preimage then Alice can still get
her money back after a timeout, breaking the MAD situation. The crucial
part making this work is that Alice won't know the fully-signed Carol
contract transaction, and so won't be able to unilaterally broadcast it.
I believe this fix makes the scheme equivalent to ZmnSCPxj's idea of
separated transactions, but without scriptless scripts (and so the
scheme is less useful)

Kind regards
CB

📅 Original date posted:2020-08-21 📝 Original message:Hello, ...

2023-06-07T18:26:15Z

In reply to nevent1q…yt6m
_________________________

📅 Original date posted:2020-08-21
📝 Original message: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 that this single UTXO is spent to two outputs: the CoinSwap 2-of-2 and the change output.
> This is because intermediate makers will have very high likelihood of generating such a pattern (it is unlikely they have an exact amount that a taker would require of them), and the occassional maker might have a very large UTXO that it can use for similar purposes.
>
> One thing a taker can do would be to multipath its CoinSwap, i.e. it spends any number of UTXOs and creates two outputs, which are actually two separate CoinSwap 2-of-2s to different makers.
> As each maker is unaware of the other, this should be similar to the case where the maker is an intermediate hop and is getting its incoming HTLC from another maker, which is unlikely to have a precise amount and will thus have a transaction that has two outputs, the 2-of-2 CoinSwap and the change.

Agreed.
I write about multipath CoinSwap routes in the original design document,
under "Combining multi-transaction with routing"

>>>> === Miner fees ===
>>>> Makers have no incentive to pay any miner fees. They only do
>>>> transactions which earn them an income and are willing to wait a very
>>>> long time for that to happen. By contrast takers want to create
>>>> transactions far more urgently. In JoinMarket we coded a protocol where
>>>> the maker could contribute to miner fees, but the market price offered
>>>> of that trended towards zero. So the reality is that takers will pay all
>>>> the miner fees. Also because makers don't know the taker's time
>>>> preference they don't know how much they should pay in miner fees.
>>>> The taker will have to set limits on how large the maker's transactions
>>>> are, otherwise makers could abuse this by having the taker consolidate
>>>> maker's UTXOs for free.
>>>
>>> Why not have the taker pay for the first maker-spent UTXO and have additional maker-spent UTXOs paid for by the maker?
>>> i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).
>>> Disagreements on feerate can be resolved by having the taker set the feerate, i.e. "the customer is always right".
>>> Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it pays for the mining fees for that extra UTXO.
>>> The maker can always reject the swap attempt if it has to spend multiple UTXOs and would lose money doing so if the taker demands a too-high feerate.
>>
>> Having the taker pay for just one UTXO will have an unfortunate side
>> effect of resulting in the maker's money being split up into a large
>> number of UTXOs, because every CoinSwap they take part in has an
>> incentive to increase their UTXO count by one. At the start of
>> JoinMarket this was an issue where then a taker wanting to CoinJoin a
>> large would come along and the result would be a huge CoinJoin
>> transaction with many many small inputs. Perhaps the taker could pay for
>> 2-3 UTXOs to counteract this. (Of course the exact number would be
>> configurable by the taker user, but defaults usually don't get changed).
>>
>> I'm still not convinced with having makers contribute to miner fees. In
>> JoinMarket we tried to get makers to contribute a little to miner fees
>> and simply they never did in any meaningful way. The market has spoken.
>> In terms of incentives makers are happy to wait a very long time, if we
>> assume they're just HODLers then even if they earn a few thousand
>> satoshis that's good.
>>
>>>> == Contract transaction definitions ==
>>>> Contract transactions are those which may spend from the 2-of-2 multisig
>>>> outputs, they transfer the coins into a contract where the coins can be
>>>> spent either by waiting for a timeout or providing a hash preimage
>>>> value. Ideally contract transactions will never be broadcast but their
>>>> existence keeps all parties honest.
>>>> M~ is miner fees, which we treat as a random variable, and ultimately
>>>> set by whichever pre-signed RBF tx get mined. When we talk about the
>>>> contract tx, we actually mean perhaps 20-30 transactions which only
>>>> differ by the miner fee and have RBF enabled, so they can be broadcasted
>>>> in sequence to get the contract transaction mined regardless of the
>>>> demand for block space.
>>>
>>> The highest-fee version could have, in addition, CPFP-anchor outputs, like those being proposed in Lightning, so even if onchain fees rise above the largest fee reservation, it is possible to add even more fees.
>>> Or not.
>>> Hmm.
>>
>> I think RBF transactions are better because they ultimately use less
>> block space than CPFP.
>>
>> There seems to be very little cost in signing many additional
>> precomputed RBF transactions. So the taker and makers could sign
>> transactions all the way up to 10000 sat/vbyte. I think this doesn't
>> apply to Lightning, because bandwidth seems to be more constrained
>> there: even a tiny micropayment for 1 satoshi would require 10x or 100x
>> more bandwidth if every lightning htlc used precomputed RBF.
>
> I was wondering if it would be a good idea actually if the **largest** fee RBF transaction had additional CPFP anchor outputs, not saying to replace the entire group of RBF transactions entirely.
>
> This is just in case of a very sudden increase in feerates that goes beyond the largest that was prepared beforehand.
> "You cannot predict the feerates future" is becoming something of a mantra over in Lightning, though I guess a "big enough" spread of RBF transactions would work in practice >99% of the time.

Got it. I agree having a CPFP anchor output on the largest fee RBF is a
good idea then.

>
>>>> (Alice+timelock_A OR Bob+hash) = Is an output which can be spent
>>>> either with Alice's private key
>>>> after waiting for a relative
>>>> timelock_A, or by Bob's private key by
>>>> revealing a hash preimage value
>>>
>>> The rationale for relative timelocks is that it makes private key turnover slightly more useable by ensuring that, after private key turnover, it is possible to wait indefinitely to spend the UTXO it received.
>>> This is in contrast with absolute timelocks, where after private key turnover, it is required to spend received UTXO before the absolute timeout.
>>> The dangers are:
>>>
>>> - Until it receives the private key, if either of the incoming or outgoing contract transactions are confirmed, every swap participant (taker or maker) should also broadcast the other contract transaction, and resolve by onchain transactions (with loss of privacy).
>>> - After receiving the private key, if the incoming contract transaction is confirmed, it should spend the resulting contract output.
>>> - It is possible to steal from a participant if that participant goes offline longer than the timeout.
>>> This may imply that there may have to be some minimum timeout that makers indicate in their advertisements.
>>> - The taker can detect if the first maker is offline, then if it is offline, try a contract transaction broadcast, if it confirms, the taker can wait for the timeout; if it times out, the taker can clawback the transaction.
>>> - This appears to be riskless for the taker.
>>> - Against a similar attack, Lightning requires channel reserves, which means the first hop never gains control of the entire value, which is a basic requirement for private key turnover.
>>> - On the other hand, the taker has the largest timeout before it can clawback the funds, so it would wait for a long time, and at any time in between the first maker can come online and spend using the hashlock branch.
>>> - But the taker can just try on the hope it works; it has nothing to lose.
>>> - This attack seems to be possible only for the taker to mount.
>>> Other makers on the route cannot know who the other makers are, without cooperation of the taker, who is the only one who knows all the makers.
>>> - On the other hand, the last maker in the route has an outgoing HTLC with the smallest timelock, so it is the least-risk and therefore a maker who notices its outgoing HTLC has a low timeout might want to just do this anyway even if it is unsure if the taker is offline.
>>
>> Every off-chain protocol like this has the livelyness requirement. Each
>> party must always be watching the chain and be ready to broadcast
>> something in response. I'm not sure how any of this relates to the
>> choice of relative vs absolute time locks.
>
> Absolute timelocks mean that you can set a timer where you put your node to sleep without risk of loss of funds (basically, once the absolute timelocks have resolved, you can forget about CoinSwaps).
> But I think the ability to spend at any time would be better, and getting 100% online 144 blocks a day, 2016 blocks a retargeting period is becoming more and more feasible.

You can always put your node to sleep as a maker, and your watchtowers
will protect you.

What do you mean by the point about 100% online nodes getting more
feasible? Many bitcoin nodes have been always-on for years, I think I
missed something.

>> You're right that attempting such an move by the taker is riskless, but
>> its not costless. The taker sets up the entire CoinSwap protocol because
>> they wanted more privacy; but if the taker broadcasts the Alice contract
>> transaction and waits for the timeout, then all they've achieved is
>> spent miner fees, got their own coin back and draw attention to it with
>> the unusual HTLC script. They've achieved no benefit from what I see, so
>> they won't do this. Any taker or maker who attempts anything like this
>> will be spending miner fees.
>
> They would be spending miner fees *from the funds being stolen*, thus still costless.
>
> In particular, let us imagine a simple 1-maker swap.
>
> * The taker and the maker complete the swap.
> * The taker now has possession of:
> * The private key for its incoming HTLC.
> * The pre-signed contract transaction for its outgoing HTLC.
> * The taker spends from its incoming HTLC using the private key.
> * The maker ignores this, because this is just normal operation.
> * Fees paid for this is not an **additional** cost, because a taker that wants to put its freshly-private funds into cold storage will do this anyway.
> * The taker gets a fresh, private coin from this incoming HTLC, so it gets the privacy it paid for.
> * The taker waits for the incoming-HTLC-spend to confirm.
> * The taker broadcasts the pre-signed contract transaction, in the hope that the maker is offline.
> * The fees paid for this are from the contract transaction that the taker is trying to steal.
> Even if the theft attempt fails, the taker has already gotten its private money out, and is thus not risking anything.
> * Semantically, the outgoing HTLC is already "owned" by the maker (the maker has private key to it).
> * Thus, the taker commits an action that the maker pays fees for!
> * The maker cannot react except to spend via the hashlock branch.
> In particular, because the taker-incoming (maker-outgoing) UTXO is already spent, it cannot retaliate by also broadcasting the contract transaction of the taker-incoming (maker-outgoing) HTLC.
> * The theft succeeds (the timelock passes) because the maker happens to be offline for that long.
> * This is "free money" to the taker, who has already gotten what it paid for --- private money in cold storage --- from the CoinSwap.
> * Even if the stolen fund reveals the contract, the taker can re-acquire privacy for the funds it stole for free, by paying for --- wait for it --- another CoinSwap for its swag.

Yep you're right, I get it.

The biggest defense against theft will have to be multiple redundant
watchtowers. But as you say the attack is riskless and costless for the
taker to attempt, so they might try anyway even if the probability of
success is very low.

If this attack becomes widespread then it effectively breaks the
property that maker's coins remain unspent indefinitely. It seems like
that would lead to makers increasing their CoinSwap fees because they
know they'll always have to spend a bit of miner fees afterwards.

Hopefully the success rate for this attack can be low enough that
taker's human niceness will stop them trying. But for sure this is a
concerning problem.

> Using an absolute timelock (implemented by a `nLockTime` tx directly off the 2-of-2, ***not*** `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 2p-ECDSA (again implemented by a tx directly off the 2-of-2) instead of a hashlock, seems to avoid this, I think, at the cost of reducing the utility of private key turnover by having a deadline where the private key *has to* be used.
> This is because there is no contract transaction that is share-owned by both participants in the swap.
> Instead there are two distinct transactions with separate ownerships: a timeout tx (that is owned by the participant paying for the HTLC/PTLC) and a claim tx (that is owned by the participant accepting the HTLC/PTLC).

A downside of using absolute timelocks is that it combines the two time
periods: the time period where a watchtower must respond and the time
period under which private keys must be used.

So for example if the absolute timelock is set to 3 weeks, that means
the maker has 3 weeks to spend their coins using the private keys which
is a nice long period. However if the CoinSwaps fails with the timeout
case then the maker has to wait 3 weeks to get their coins back, which
is a long time.

We can go the other extreme and set the absolute timelock to be 2 days.
Then the maker only has to wait 2 days in the unfortunate event that
their coinswap fails with the timeout case. But it means they must use
their private keys to spend coins within the short period of 2 days(!)

Though this still might be worth it to solve the riskless/costless
stealing attempts.

>>> - Participants might want to spend from the UTXO to a new address after private key turnover anyway.
>>> Makers could spend using a low-fee RBF-enabled tx, and when another request comes in for another swap, try to build a new funding tx with a higher-fee bump.
>>>
>>
>> I don't think this will happen very often. It's spending money on block
>> space for not much benefit. If the maker ever decides to shut down their
>> maker they can transfer all their coins in HTLCs to single-sig
>> transactions exclusively controlled by them, but in normal operation I
>> doubt it will happen.
>
> Accidents can happen (e.g. somebody trips over the power cord of the maker hardware), so hedging this somewhat might give a useful safety net.

Right, but taking out the maker hardware isn't enough for funds to be
stolen, all the watchtowers would need to be taken out too.

>>>> == EC tweak to reduce one round trip ==
>>>> When two parties are agreeing on a 2-of-2 multisig address, they need to
>>>> agree on their public keys. We can avoid one round trip by using the EC
>>>> tweak trick.
>>>> When Alice, the taker, downloads the entire offer book for the liquidity
>>>> market, the offers will also contain a EC public key. Alice can tweak
>>>> this to generate a brand new public key for which the maker knows the
>>>> private key. This public key will be one of the keys in the 2-of-2
>>>> multisig. This feature removes one round trip from the protocol.
>>>> q = EC privkey generated by maker
>>>> Q = q.G = EC pubkey published by maker
>>>> p = nonce generated by taker
>>>> P = p.G = nonce point calculated by taker
>>>> R = Q + P = pubkey used in bitcoin transaction
>>>> = (q + p).G
>>>
>>> Whoa whoa whoa whoa.
>>> All this time I was thinking you were going to use 2p-ECDSA for all 2-of-2s.
>>> In which case, the private key generated by the taker would be sufficient tweak to blind this.
>>> In 2p-ECDSA, for two participants M = m * G; T = t * G, the total key is m * t * G = m * T = t * M.
>>> Are you going to use `2 <T> <Q+P> 2 OP_CHECKMULTISIG` instead of 2p-ECDSA?
>>> Note that you cannot usefully hide among Lightning mutual closes, because of the reserve; Lightning mutual closes are very very likely to be spent in a 1-input (that spends from a 2-of-2 P2WSH), 2-output (that pays to two P2WPKHs) tx.
>>
>> Yes, I intend for 2p-ECDSA to be used eventually, but for the first
>> version I'll only implement regular multisigs with OP_CHECKMULTISIG.
>> Once all the other details of this protocol are implemented correctly
>> and mostly-bug-free then 2p-ECDSA can be added. It can be added in the
>> protocol steps 0-1, 3-5 and 7-9.
>
> Okay, that is clearer.
>
> I think 2p-ECDSA should be first priority after getting a decent alpha version.
>
>> This document also doesn't talk about PayJoin-with-CoinSwap, but that
>> can be added later too.
>
> 2p-ECDSA with Scriptless Script potentially gives a lot more privacy than any PayJoin IMO, due simply to the much larger anonymity set, and there are enough chain-analysis-heuristic-breaking shenanigans we can implement with plain CoinSwap, I think.

I completely agree.

Regards
CB

📅 Original date posted:2020-08-20 📝 Original message:Hello ...

2023-06-07T18:26:14Z

In reply to nevent1q…tcmf
_________________________

📅 Original date posted:2020-08-20
📝 Original message: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
>>> P = p.G = nonce point calculated by taker
>>>
>>> R = Q + P = pubkey used in bitcoin transaction
>>> = (q + p).G
>>
>> If I'm understanding this correctly (which I'm not sure I ame), it seems like the plan is to put R on-chain as the key to an output? As stated this is completely insecure as Q is known in advance so the taker can always choose a nonce p but then claim that their nonce point is p.G - Q so that the key that goes on-chain is (p.G - Q + Q) = p.G allowing them to steal the funds.
>
> My reading from this is that nonce `p` has to be given by the taker to the maker outright.
> In original post:
>
>> Taker sends unsigned transaction which pays to multisig using pubkey Q,
>> and also sends nonce p.
>
> Thus, taker provides a proof-of-knowledge, i.e. the actual `p` scalar itself (not zero-knowledge, but what the maker needs is proof-of-knowledge, and could not care less if the proof is zero-knowledge or not).

Yes this looks right. In hindsight my text could be clarified by
changing the relevant lines to:

p = nonce generated by taker, sent to maker
P = p.G = nonce point calculated by taker

R = Q + P = pubkey used in bitcoin transaction, calculated by taker
= (q + p).G = same pubkey, calculated by maker

I don't think the key subtraction attack described by Nadav will work
here...?

> On the other hand, I do not see the point of this tweak if you are going to use 2p-ECDSA, since my knowledge is that 2p-ECDSA uses the pubkey that is homomorphic to the product of the private keys.
> And that pubkey is already tweaked, by the fresh privkey of the maker (and the maker is buying privacy and wants security of the swap, so is incentivized to generate high-entropy temporary privkeys for the actual swap operation).
>
> Not using 2p-ECDSA of some kind would remove most of the privacy advantages of CoinSwap.
> You cannot hide among `2 <A> <B> 2 OP_CHECKMULTISIG` scripts of Lightning, because:
>
> * Lightning channel closes tend to be weeks at least after the funding outpoint creation, whereas CoinSwap envisions hours or days.
> * Lightning mutual channel closes have a very high probability of spending to two P2WPKH addresses.
>
> You need to hide among the much larger singlesig anonymity set, which means using a single signature (created multiparty by both participants), not two signatures (one from each participant).
>
> Or is this intended for HTLCs in open-coded SCRIPTs `OP_DUP OP_IF OP_HASH160 <hash> OP_EQUAL <A> OP_ELSE <time> OP_CHECKSEQUENCEVERIFY OP_DROP <B> OP_ENDIF OP_CHECKSIG`?
> This provides a slight privacy boost in a case (contract transaction publication) where most of the privacy is lost anyway.

I completely agree that 2of2 multisigs made with OP_CHECKMULTISIG are
lacking in terms of privacy, and that 2p-ECDSA is much better. However
this whole protocol is quite complicated and I thought it would be a
good move to first implement it with OP_CHECKMULTISIG, to get all the
other details right (miner fees, coinswap fees, private key handover,
contract transactions, tor hidden services, watchtowers, etc etc) and
then add 2p-ECDSA later. Of course in that case all this tweaking of
public keys would be superseded by the 2p-ECDSA protocol.

📅 Original date posted:2020-08-20 📝 Original message:Hello ...

2023-06-07T18:26:14Z

In reply to nevent1q…xdmt
_________________________

📅 Original date posted:2020-08-20
📝 Original message: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 know
>> their previous and next transactions. Bob and Charlie do not have direct
>> connections with each other, only with Alice.
>>
>> Diagram of Tor connections:
>>
>> Bob Charlie
>> | /
>> | /
>> | /
>> Alice
>>
>> When Bob and Charlie communicate, they are actually sending and
>> receiving messages via Alice who relays them to Charlie or Bob. This
>> helps hide whether the previous or next counterparty in a CoinSwap route
>> is a maker or taker.
>>
>> This doesn't have security issues even in the final steps where private
>> keys are handed over, because those private keys are always for 2-of-2
>> multisig and so on their own are never enough to steal money.
>
> This has a massive advantage over CoinJoin.
>
> In CoinJoin, since all participants sign a single transaction, every participant knows the total number of participants.
> Thus, in CoinJoin, it is fairly useless to have just one taker and one maker, the maker knows exactly which output belongs to the taker.
> Even if all communications were done via the single paying taker, the maker(s) are shown the final transaction and thus can easily know how many participants there are (by counting the number of equal-valued outputs).
>
> With CoinSwap, in principle no maker has to know how many other makers are in the swap.
>
> Thus it would still be useful to make a single-maker CoinSwap, as that would be difficult, for the maker, to diferentiate from a multi-maker CoinSwap.

Yes great point.

> There are still a few potential leaks though:
>
> * If paying through a CoinSwap, the cheapest option for the taker would be to send out a single large UTXO (single-output txes) to the first maker, and then demand the final payment and any change as two separate swaps from the final maker.
> * Intermediate makers are likely to not have exact amounts, thus is unlikely to create a single-output tx when forwarding.
> * Thus, the first maker could identify the taker.

Right, so if the taker uses only a single maker then they must have more
than one UTXO.

This leak in the case of a taker spending a single UTXO also happens
when the taker needs to create a branching route. I described this in my
original email "Design for a CoinSwap implementation for massively
improving Bitcoin privacy and fungibility" under the section "Combining
multi-transaction with routing" (the second diagram).

I think this might be unavoidable. If the taker has just one UTXO they'd
be much better off using multiple makers for this reason.

> * The makers can try timing the communications lag with the taker.
> The general assumption would be that more makers == more delay in taker responses.

Sounds like adding random delays would fix this. The protocol already
involves waiting for a confirmation (average waiting time 10 minutes, at
best) and might involve more confirmations for extra security and
privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause
too many issues.
Also the Tor network can be pretty laggy so that might add enough noise
anyway.

>>
>> === Miner fees ===
>>
>> Makers have no incentive to pay any miner fees. They only do
>> transactions which earn them an income and are willing to wait a very
>> long time for that to happen. By contrast takers want to create
>> transactions far more urgently. In JoinMarket we coded a protocol where
>> the maker could contribute to miner fees, but the market price offered
>> of that trended towards zero. So the reality is that takers will pay all
>> the miner fees. Also because makers don't know the taker's time
>> preference they don't know how much they should pay in miner fees.
>>
>> The taker will have to set limits on how large the maker's transactions
>> are, otherwise makers could abuse this by having the taker consolidate
>> maker's UTXOs for free.
>
> Why not have the taker pay for the *first* maker-spent UTXO and have additional maker-spent UTXOs paid for by the maker?
> i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs).
>
> Disagreements on feerate can be resolved by having the taker set the feerate, i.e. "the customer is always right".
> Thus if the maker *has to* spend two UTXOs to make up the 0.4 BTC bag, it pays for the mining fees for that extra UTXO.
> The maker can always reject the swap attempt if it *has to* spend multiple UTXOs and would lose money doing so if the taker demands a too-high feerate.

Having the taker pay for just one UTXO will have an unfortunate side
effect of resulting in the maker's money being split up into a large
number of UTXOs, because every CoinSwap they take part in has an
incentive to increase their UTXO count by one. At the start of
JoinMarket this was an issue where then a taker wanting to CoinJoin a
large would come along and the result would be a huge CoinJoin
transaction with many many small inputs. Perhaps the taker could pay for
2-3 UTXOs to counteract this. (Of course the exact number would be
configurable by the taker user, but defaults usually don't get changed).

I'm still not convinced with having makers contribute to miner fees. In
JoinMarket we tried to get makers to contribute a little to miner fees
and simply they never did in any meaningful way. The market has spoken.
In terms of incentives makers are happy to wait a very long time, if we
assume they're just HODLers then even if they earn a few thousand
satoshis that's good.

>> == Contract transaction definitions ==
>>
>> Contract transactions are those which may spend from the 2-of-2 multisig
>> outputs, they transfer the coins into a contract where the coins can be
>> spent either by waiting for a timeout or providing a hash preimage
>> value. Ideally contract transactions will never be broadcast but their
>> existence keeps all parties honest.
>>
>> M~ is miner fees, which we treat as a random variable, and ultimately
>> set by whichever pre-signed RBF tx get mined. When we talk about the
>> contract tx, we actually mean perhaps 20-30 transactions which only
>> differ by the miner fee and have RBF enabled, so they can be broadcasted
>> in sequence to get the contract transaction mined regardless of the
>> demand for block space.
>
> The highest-fee version could have, in addition, CPFP-anchor outputs, like those being proposed in Lightning, so even if onchain fees rise above the largest fee reservation, it is possible to add even more fees.
>
> Or not.
> Hmm.

I think RBF transactions are better because they ultimately use less
block space than CPFP.

There seems to be very little cost in signing many additional
precomputed RBF transactions. So the taker and makers could sign
transactions all the way up to 10000 sat/vbyte. I think this doesn't
apply to Lightning, because bandwidth seems to be more constrained
there: even a tiny micropayment for 1 satoshi would require 10x or 100x
more bandwidth if every lightning htlc used precomputed RBF.

> Another thought: later you describe that miner fees are paid by Alice by forwarding those fees as well, how does that work when there are multiple versions of the contract transaction?

Alice only pays the miner fees for the funding transactions, not the
contract transaction. The miner fees for the contract transactions are
taken from the contract balance. The contract transactions are 1-input
1-output, and whoever ends up with the money will be the one who paid
the miner fee.

>> (Alice+timelock_A OR Bob+hash) = Is an output which can be spent
>> either with Alice's private key
>> after waiting for a relative
>> timelock_A, or by Bob's private key by
>> revealing a hash preimage value
>
> The rationale for relative timelocks is that it makes private key turnover slightly more useable by ensuring that, after private key turnover, it is possible to wait indefinitely to spend the UTXO it received.
> This is in contrast with absolute timelocks, where after private key turnover, it is required to spend received UTXO before the absolute timeout.
>
> The dangers are:
>
> * Until it receives the private key, if either of the incoming or outgoing contract transactions are confirmed, every swap participant (taker or maker) should also broadcast the other contract transaction, and resolve by onchain transactions (with loss of privacy).
> * After receiving the private key, if the incoming contract transaction is confirmed, it should spend the resulting contract output.
> * It is possible to steal from a participant if that participant goes offline longer than the timeout.
> This may imply that there may have to be some minimum timeout that makers indicate in their advertisements.
> * The taker can detect if the first maker is offline, then if it is offline, try a contract transaction broadcast, if it confirms, the taker can wait for the timeout; if it times out, the taker can clawback the transaction.
> * This appears to be riskless for the taker.
> * Against a similar attack, Lightning requires channel reserves, which means the first hop never gains control of the entire value, which is a basic requirement for private key turnover.
> * On the other hand, the taker has the largest timeout before it can clawback the funds, so it would wait for a long time, and at any time in between the first maker can come online and spend using the hashlock branch.
> * But the taker can just try on the hope it works; it has nothing to lose.
> * This attack seems to be possible only for the taker to mount.
> Other makers on the route cannot know who the other makers are, without cooperation of the taker, who is the only one who knows all the makers.
> * On the other hand, the last maker in the route has an outgoing HTLC with the smallest timelock, so it is the least-risk and therefore a maker who notices its outgoing HTLC has a low timeout might want to just do this anyway even if it is unsure if the taker is offline.

Every off-chain protocol like this has the livelyness requirement. Each
party must always be watching the chain and be ready to broadcast
something in response. I'm not sure how any of this relates to the
choice of relative vs absolute time locks.

You're right that attempting such an move by the taker is riskless, but
its not costless. The taker sets up the entire CoinSwap protocol because
they wanted more privacy; but if the taker broadcasts the Alice contract
transaction and waits for the timeout, then all they've achieved is
spent miner fees, got their own coin back and draw attention to it with
the unusual HTLC script. They've achieved no benefit from what I see, so
they won't do this. Any taker or maker who attempts anything like this
will be spending miner fees.

I also envision that makers will run their own personal "watchtowers",
similar to watchtowers in the lightning world, which would watch the
blockchain and be ready to broadcast a transaction. In terms of
incentives, makers are HODLers and we can expect them to protect their
stash very carefully by running perhaps multiple redundant watchtowers
in multiple locations and multiple networks. Therefore a taker noticing
that a maker's .onion is down does not imply that all the maker's
watchtowers are down.

Of course we will choose the timelocks to be long enough so that
everyone has enough time to broadcast a transaction in response, even in
times of congested mempools.

> * Participants might want to spend from the UTXO to a new address after private key turnover anyway.
> Makers could spend using a low-fee RBF-enabled tx, and when another request comes in for another swap, try to build a new funding tx with a higher-fee bump.

I don't think this will happen very often. It's spending money on block
space for not much benefit. If the maker ever decides to shut down their
maker they can transfer all their coins in HTLCs to single-sig
transactions exclusively controlled by them, but in normal operation I
doubt it will happen.

>> A possible attack by a malicious Alice is that she chooses M1 to be very
>> low (e.g. 1 sat/vbyte) and sets M2 and M3 to be very high (e.g. 1000
>> sat/vb) and then intentionally aborts, forcing the makers to lose much
>> more money in miner fees than the attacker. The attack can be used to
>> waste away Bob's and Charlie's coins on miner fees at little cost to the
>> malicious taker Alice. So to defend against this attack Bob and Charlie
>> must refuse to sign a contract transaction if the corresponding funding
>> transaction pays miner fees greater than Alice's funding transaction.
>
> Sorry, I do not follow the logic for this...?

I'll try to explain again with an example, hopefully it clarifies.

Recall the table of balances before/after CoinSwap using contracts
transactions:

Party | Before | After
--------|--------|--------------------------------------------
Alice | WA | WA-M1-I + I-MA~ = WA-M1-MA~
Bob | WB | WB-I+B + I-M2-B-MB~ = WB-M2-MB~

What the table says is that if the CoinSwap results in the HTLC
transactions being mined and the locktime branch being used, then both
Alice and Bob will see their wallet balance fall by two miner fees (in
Alice's case the miner fee of the Alice funding transaction plus the
miner fee of the Alice contract transaction).

The attack I describe works because Alice chooses both MA~ and MB~. The
attack is that Alice chooses MA~ to be a very low value (e.g. 1 sat/vb)
and chooses MB~ to be a very high value (e.g. 1000 sat/vb). Then Alice
intentionally sabotages the CoinSwap and forces it to go to the timeout
case, what happens is that Bob's wallet balance falls by much more than
Alice's, because MB~ > MA~. So this is a DOS attack: Alice can waste
Bob's resources without wasting much of her own.

>> The timelocks are staggered so that if Alice uses the preimage to take
>> coins then the right people will also learn the preimage and have enough
>> time to be able to get their coins back too. Alice starts with knowledge
>> of the hash preimage so she must have a longest timelock.
>
> More precisely:
>
> * The HTLC outgoing from Alice has the longest timelock.
> * The HTLC incoming into Alice has the shortest timelock.
>
> For the makers, they only need to ensure that the incoming timelock is much larger than the outgoing timelock.

Agreed.

Perhaps I chose confusing terminology, "Alice contract transaction"
means the transaction which pays money to Alice after a timeout. The
text you quoted is confusingly written, and it would've been better to
write: "Alice starts with knowledge of the hash preimage so the Alice
contract transaction must have a longest timelock."

>> == EC tweak to reduce one round trip ==
>>
>> When two parties are agreeing on a 2-of-2 multisig address, they need to
>> agree on their public keys. We can avoid one round trip by using the EC
>> tweak trick.
>>
>> When Alice, the taker, downloads the entire offer book for the liquidity
>> market, the offers will also contain a EC public key. Alice can tweak
>> this to generate a brand new public key for which the maker knows the
>> private key. This public key will be one of the keys in the 2-of-2
>> multisig. This feature removes one round trip from the protocol.
>>
>> q = EC privkey generated by maker
>> Q = q.G = EC pubkey published by maker
>>
>> p = nonce generated by taker
>> P = p.G = nonce point calculated by taker
>>
>> R = Q + P = pubkey used in bitcoin transaction
>> = (q + p).G
>
> Whoa whoa whoa whoa.
>
> All this time I was thinking you were going to use 2p-ECDSA for all 2-of-2s.
> In which case, the private key generated by the taker would be sufficient tweak to blind this.
>
> In 2p-ECDSA, for two participants M = m * G; T = t * G, the total key is m * t * G = m * T = t * M.
>
> Are you going to use `2 <T> <Q+P> 2 OP_CHECKMULTISIG` instead of 2p-ECDSA?
> Note that you cannot usefully hide among Lightning mutual closes, because of the reserve; Lightning mutual closes are very very likely to be spent in a 1-input (that spends from a 2-of-2 P2WSH), 2-output (that pays to two P2WPKHs) tx.

Yes, I intend for 2p-ECDSA to be used eventually, but for the first
version I'll only implement regular multisigs with OP_CHECKMULTISIG.
Once all the other details of this protocol are implemented correctly
and mostly-bug-free then 2p-ECDSA can be added. It can be added in the
protocol steps 0-1, 3-5 and 7-9.

This document also doesn't talk about PayJoin-with-CoinSwap, but that
can be added later too.

>>
>> == Analysis of deviations ==
>>
>> This section discusses what happens if one party deviates from the
>> protocol by doing something else, for example broadcasting a htlc
>> contract tx when they shouldnt have.
>>
>> The party name refers to what that party does, followed by other party's
>> reactions to it.
>> e.g. Party1: does a thing, Party2/Party3: does a thing in reaction
>>
>> If multiple deviations are possible in a step then they are numbered
>> e.g. A1 A2 A2 etc
>>
>> 0-2. Alice/Bob/Charlie: nothing else is possible except following the
>> protocol or aborting
>>
>> 8. Alice: broadcasts one or more of the A htlc txes. Bob/Charlie/Dennis:
>> do nothing, they havent lost any time or money.
>> 4-6. Bob/Charlie: nothing else is possible except following the protocol
>> or aborting.
>>
>> 9. Bob: broadcasts one or more of the B htlc txes, Alice: broadcasts all
>> her own A htlc txes and waits for the timeout to get her money back.
>> Charlie: do nothing
>>
>> 10. Charlie: nothing else is possible except following the protocol or
>> aborting.
>>
>> 11. Alice: broadcasts one or more of the A htlc txes. Bob: broadcasts all
>> his own A htlc txes and waits for the timeout.
>> A. same as 8.
>> B. Charlie: broadcasts one or more of the C htlc txes, Alice/Bob:
>> broadcasts all their own htlc txes and waits for the timeout to get
>> their money back.
>> C-E1. Alice: broadcasts all of C htlc txes and uses her knowledge of the
>> preimage hash to take the money immediately. Charlie: broadcasts
>> all of B htlc txes and reading the hash value from the blockchain,
>> uses it to take the money from B htlc immediately. Bob: broadcasts
>> all of A htlc txes, and reading hash from the blockchain, uses it
>> to take the money from A htlc immediately.
>> C-E2. Alice: broadcast her own A htlc txes, and after a timeout take the
>> money. Bob: broadcast his own B htlc txes and after the timeout
>> take their money. Charlie: broadcast his own C htlc txes and after
>> the timeout take their money.
>> F1. Bob: broadcast one or more of A htcl txes and use the hash preimage
>> to get the money immediately. He already knows both privkeys of the
>> multisig so this is pointless and just damages privacy and wastes
>> miner fees. Alice: blacklist Bob's fidelity bond.
>> F2. Bob: broadcast one or more of the C htlc txes. Charlie: use preimage
>> to get his money immediately. Bob's actions were pointless. Alice:
>> cant tell whether Bob or Charlie actually broadcasted, so blacklist
>> both fidelity bonds.
>> G1. Charlie: broadcast one or more of B htcl txes and use the hash
>> preimage to get the money immediately. He already knows both
>> privkeys of the multisig so this is pointless and just damages
>> privacy and wastes miner fees. Alice: cant tell whether Bob or
>> Charlie actually broadcasted, so blacklist both fidelity bonds.
>> G2. Charlie: broadcast one or more of the A htlc txes. Alice: broadcast
>> the remaining A htlc txes and use preimage to get her money
>> immediately. Charlies's actions were pointless. Alice: blacklist
>> Charlie's fidelity bond.
>>
>> The multisig outputs of the funding transactions can stay unspent
>> indefinitely. However the parties must always be watching the network
>> and ready to respond with their own sweep using a preimage. This is
>> because the other party still possesses a fully-signed contract tx. The
>> parties respond in the same way as in steps C-E1, F2 and G2. Alice's
>> reaction of blacklisting both fidelity bonds might not be the right way,
>> because one maker could use it to get another one blacklisted (as well
>> as themselves).
>
> Looks OK, though note that a participant might try to do so (as pointed out above) in the hope that the next participant is offline.

I really hope that everyone (the makers at least) is running multiple
redundant watchtowers, so that anyone attempting this attack just wastes
money on miner fees and achieves nothing.

📅 Original date posted:2020-08-11 📝 Original ...

2023-06-07T18:26:11Z

In reply to nevent1q…pwwm
_________________________

📅 Original date posted:2020-08-11
📝 Original message: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 use
them. Once CoinSwap is deployed, anyone attempting surveillance of
bitcoin transactions will be forced to ask themselves the question: how
do we know this transaction wasn't a CoinSwap?

This email contains a detailed design of the first protocol version. It
makes use of the building blocks of multi-transaction CoinSwaps, routed
CoinSwaps, liquidity market, private key handover, and fidelity bonds.
It does not include PayJoin-with-CoinSwap, but that's in the plan to be
added later.

== Routed CoinSwap ==

Diagram of CoinSwaps in the route:

Alice ====> Bob ====> Charlie ====> Alice

Where (====>) means one CoinSwap. Alice gives coins to Bob, who gives
coins to Charlie, who gives coins to Alice. Alice is the market taker
and she starts with the hash preimage. She chooses the CoinSwap amount
and chooses who the makers will be.

This design has one market taker and two market makers in its route, but
it can easily be extended to any number of makers.

== Multiple transactions ==

Each single CoinSwap is made up of multiple transactions to avoid amount
correlation

(a0 BTC) ---> (b0 BTC) ---> (c0 BTC) --->
Alice (a1 BTC) ---> Bob (b1 BTC) ---> Charlie (c1 BTC) ---> Alice
(a2 BTC) ---> (b2 BTC) ---> (c2 BTC) --->

The arrow (--->) represent funding transactions. The money gets paid to
a 2-of-2 multisig but after the CoinSwap protocol and private key
handover is done they will be controlled by the next party in the route.

This example has 6 regular-sized transactions which use approximately
the same amount of block space as a single JoinMarket coinjoin with 6
parties (1 taker, 5 makers). Yet the privacy provided by this one
CoinSwap would be far far greater. It would not have to be repeated in
the way that Equal-Output CoinJoins must be.

== Direct connections to Alice ===

Only Alice, the taker, knows the entire route, Bob and Charlie just know
their previous and next transactions. Bob and Charlie do not have direct
connections with each other, only with Alice.

Diagram of Tor connections:

Bob Charlie
| /
| /
| /
Alice

When Bob and Charlie communicate, they are actually sending and
receiving messages via Alice who relays them to Charlie or Bob. This
helps hide whether the previous or next counterparty in a CoinSwap route
is a maker or taker.

This doesn't have security issues even in the final steps where private
keys are handed over, because those private keys are always for 2-of-2
multisig and so on their own are never enough to steal money.

=== Miner fees ===

Makers have no incentive to pay any miner fees. They only do
transactions which earn them an income and are willing to wait a very
long time for that to happen. By contrast takers want to create
transactions far more urgently. In JoinMarket we coded a protocol where
the maker could contribute to miner fees, but the market price offered
of that trended towards zero. So the reality is that takers will pay all
the miner fees. Also because makers don't know the taker's time
preference they don't know how much they should pay in miner fees.

The taker will have to set limits on how large the maker's transactions
are, otherwise makers could abuse this by having the taker consolidate
maker's UTXOs for free.

== Funding transaction definitions ==

Funding transactions are those which pay into the 2-of-2 multisig addresses.

Definitions:
I = initial coinswap amount sent by Alice = a0 + a1 + a2
(WA, WB, WC) = Total value of UTXOs being spent by Alice, Bob, Charlie
respectively. Could be called "wallet Alice", "wallet
Bob", etc
(B, C) = Coinswap fees paid by Alice and earned by Bob and Charlie.
(M1, M2, M3) = Miner fees of the first, second, third, etc sets of
funding transactions. Alice will choose what these are
since she's paying.
multisig(A+B) = A 2of2 multisig output with private keys held by A and B

The value in square parentheses refers to the bitcoin amount.

Alice funding txes
[WA btc] ---> multisig (Alice+Bob) [I btc]
change [WA-M1-I btc]
Bob funding txes
[WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc]
change [WB-I+B btc]
Charlie funding txes
[WC btc] ---> multisig (Charlie+Alice) [(I-M2-B)-M3-C btc]
change [WC-(I-M2-B)+C btc]

Here we've drawn these transactions as single transactions, but they are
actually multiple transactions where the outputs add up some value (e.g.
add up to I in Alice's transactions.)

=== Table of balances before and after a successful CoinSwap ===

If a CoinSwap is successful then all the multisig outputs in the funding
transactions will become controlled unilaterally by one party. We can
calculate how the balances of each party change.

Party | Before | After
--------|--------|-------------------------------------------
Alice | WA | WA-M1-I + (I-M2-B)-M3-C = WA-M1-M2-M3-B-C
Bob | WB | WB-I+B + I = WB+B
Charlie | WC | WC-(I-M2-B)+C + I-M2-B = WC+C

After a successful coinswap, we see Alice's balance goes down by the
miner fees and the coinswap fees. Bob's and Charlie's balance goes up by
their coinswap fees.

== Contract transaction definitions ==

Contract transactions are those which may spend from the 2-of-2 multisig
outputs, they transfer the coins into a contract where the coins can be
spent either by waiting for a timeout or providing a hash preimage
value. Ideally contract transactions will never be broadcast but their
existence keeps all parties honest.

M~ is miner fees, which we treat as a random variable, and ultimately
set by whichever pre-signed RBF tx get mined. When we talk about _the_
contract tx, we actually mean perhaps 20-30 transactions which only
differ by the miner fee and have RBF enabled, so they can be broadcasted
in sequence to get the contract transaction mined regardless of the
demand for block space.

(Alice+timelock_A OR Bob+hash) = Is an output which can be spent
either with Alice's private key
after waiting for a relative
timelock_A, or by Bob's private key by
revealing a hash preimage value

Alice contract tx:
multisig (Alice+Bob) ---> (Alice+timelock_A OR Bob+hash)
[I btc] [I-M~ btc]
Bob contract tx:
multisig (Bob+Charlie) ---> (Bob+timelock_B OR Charlie+hash)
[I-M2-B btc] [I-M2-B-M~ btc]
Charlie contract tx:
multisig (Charlie+Alice) ---> (Charlie+timelock_C OR Alice+hash)
[(I-M2-B)-M3-C btc] [(I-M2-B)-M3-C-M~ btc]

=== Table of balances before/after CoinSwap using contracts transactions ===

In this case the parties had to get their money back by broadcasting and
mining the contract transactions and waiting for timeouts.

Party | Before | After
--------|--------|--------------------------------------------
Alice | WA | WA-M1-I + I-M~ = WA-M1-M~
Bob | WB | WB-I+B + I-M2-B-M~ = WB-M2-M~
Charlie | WC | WC-(I-M2-B)+C + (I-M2-B)-M3-C-M~ = WC-M3-M~

In the timeout failure case, every party pays for their own miner fees.
And nobody earns or spends any coinswap fees. So even for a market maker
its possible for their wallet balance to go down sometimes, although as
we shall see there are anti-DOS features which make this unlikely to
happen often.

A possible attack by a malicious Alice is that she chooses M1 to be very
low (e.g. 1 sat/vbyte) and sets M2 and M3 to be very high (e.g. 1000
sat/vb) and then intentionally aborts, forcing the makers to lose much
more money in miner fees than the attacker. The attack can be used to
waste away Bob's and Charlie's coins on miner fees at little cost to the
malicious taker Alice. So to defend against this attack Bob and Charlie
must refuse to sign a contract transaction if the corresponding funding
transaction pays miner fees greater than Alice's funding transaction.

There can also be a failure case where each party gets their money using
hash preimage values instead of timeouts. Note that each party has to
sweep the output before the timeout expires, so that will cost an
additional miner fee M~.

Party | Before | After
--------|--------|------------------------------------------------------
Alice | WA | WA-M1-I + (I-M2-B)-M3-C-M~ - M~ = WA-M1-M2-M3-B-C-2M~
Bob | WB | WB-I+B + I-M~ - M~ = WB+B-2M~
Charlie | WC | WC-(I-M2-B)+C + I-M2-B-M~ - M~ = WC+C-2M~

In this situation the makers Bob and Charlie earn their CoinSwap fees,
but they pay an additional miner fee twice. Alice pays for all the
funding transaction miner fees, and the CoinSwap fees, and two
additional miner fees. And she had her privacy damaged because the
entire world saw on the blockchain the contract script.

Using the timelock path is like a refund, everyone's coin just comes
back to them. Using the preimage is like the CoinSwap transaction
happened, with the coins being sent ahead one hop. Again note that if
the preimage is used then coinswap fees are paid.

=== Staggered timelocks ===

The timelocks are staggered so that if Alice uses the preimage to take
coins then the right people will also learn the preimage and have enough
time to be able to get their coins back too. Alice starts with knowledge
of the hash preimage so she must have a longest timelock.

== EC tweak to reduce one round trip ==

When two parties are agreeing on a 2-of-2 multisig address, they need to
agree on their public keys. We can avoid one round trip by using the EC
tweak trick.

When Alice, the taker, downloads the entire offer book for the liquidity
market, the offers will also contain a EC public key. Alice can tweak
this to generate a brand new public key for which the maker knows the
private key. This public key will be one of the keys in the 2-of-2
multisig. This feature removes one round trip from the protocol.

q = EC privkey generated by maker
Q = q.G = EC pubkey published by maker

p = nonce generated by taker
P = p.G = nonce point calculated by taker

R = Q + P = pubkey used in bitcoin transaction
= (q + p).G

Taker sends unsigned transaction which pays to multisig using pubkey Q,
and also sends nonce p. The maker can use nonce p to calculate (q + p)
which is the private key of pubkey R.

Taker doesnt know the privkey because they are unable to find q because
of the ECDLP.

Any eavesdropper can see the nonce p and easily calculate the point R
too but Tor communication is encrypted so this isnt a concern.

None of the makers in the route know each other's Q values, so Alice the
taker will generate a nonce p on their behalf and send it over. I
believe this cant be used for any kind of attack, because the signing
maker will always check that the nonce results in the public key
included in the transaction they're signing, and they'll never sign a
transaction not in their interests.

== Protocol ==

This section is the most important part of this document.

Definitions:
fund = all funding txes (remember in this multi-tx protocol there can be
multiple txes which together make up the funding)
A htlc = all htlc contract txes (fully signed) belonging to party A
A unsign htcl = all unsigned htlc contract txes belonging to party A
including the nonce point p used to calculate the
maker's pubkey.
p = nonce point p used in the tweak EC protocol for calculating the
maker's pubkey
A htlc B/2 = Bob's signature for the 2of2 multisig of the Alice htlc
contract tx
privA(A+B) = private key generated by Alice in the output
multisig (Alice+Bob)

| Alice | Bob | Charlie |
|=================|=================|=================|
0. A unsign htlc ----> | |
1. <---- A htlc B/2 | |
2. ***** BROADCAST AND MINE ALICE FUNDING TXES ****** |
3. A fund+htlc+p ----> | |
4. | B unsign htlc ----> |
5. | <---- B htlc C/2 |
6. ******* BROADCAST AND MINE BOB FUNDING TXES ******* |
7. | B fund+htlc+p ----> |
8. <---------------------- C unsign htlc |
9. C htlc A/2 ----------------------> |
A. ***** BROADCAST AND MINE CHARLIE FUNDING TXES ***** |
B. <---------------------- C fund+htlc+p |
C. hash preimage ----------------------> |
D. hash preimage ----> | |
E. privA(A+B) ----> | |
F. | privB(B+C) ----> |
G. <---------------------- privC(C+A) |

== Protocol notes ==
0-2 are the steps which setup Alice's funding tx and her contract tx for
possible refund
4-5 same as 0-2 but for Bob
8-9 same as 0-2 but for Charlie
3,7 is proof to the next party that the previous party has already
committed miner fees to getting a transaction mined, and therefore
this isnt a DOS attack. The step also reveals the fully-signed
contract transaction which the party can use to get their money back
with a preimage.
C-G is revealing the hash preimage to all, and handing over the private
keys

== Analysis of aborts ==

We will now discuss aborts, which happen when one party halts the
protocol and doesnt continue. Perhaps they had a power cut, their
internet broke, or they're a malicious attacker wanting to waste time
and money. The other party may try to reestablish a connection for some
time, but eventually must give up.

Number refers to the step number where the abort happened
e.g. step 1 means that the party aborted instead of the action happening
on protocol step 1.

The party name refers to what that party does
e.g. Party1: aborts, Party2/Party3: does a thing in reaction

0. Alice: aborts. Bob/Charlie: do nothing, they havent lost any time or
money
1. Bob: aborts. Alice: lost no time or money, try with another Bob.
Charlie: do nothing
2-3. same as 0.
4. Bob: aborts. Charlie: do nothing. Alice: broadcasts her contract tx
and waits for the timeout, loses time and money on miner fees, she'll
never coinswap with Bob's fidelity bond again.
5. Charlie: aborts. Alice/Bob: lose nothing, find another Charlie to
coinswap with.
6. same as 4.
7. similar to 4 but Alice MIGHT not blacklist Bob's fidelity bond,
because Bob will also have to broadcast his contract tx and will also
lose time and money.
8. Charlie: aborts. Bob: broadcast his contract transaction and wait for
the timeout to get his money back, also broadcast Alice's contract
transaction in retaliation. Alice: waits for the timeout on her htlc
tx that Bob broadcasted, will never do a coinswap with Charlie's
fidelity bond again.
9. Alice: aborts. Charlie: do nothing, no money or time lost. Bob:
broadcast bob contract tx and wait for timeout to get money back,
comforted by the knowledge that when Alice comes back online she'll
have to do the same thing and waste the same amount of time and
money.
A-B. same as 8.
C-E. Alice: aborts. Bob/Charlie: all broadcast their contract txes and
wait for the timeout to get their money back, or if Charlie knows
the preimage he uses it to get the money immediately, which Bob can
read from the blockchain and also use.
F. Bob: aborts. Alice: broadcast Charlie htlc tx and use preimage to get
money immediately, Alice blacklists Bob's fidelity bond. Charlie:
broadcast Bob htlc and use preimage to get money immediately.
G. Charlie: aborts. Alice: broadcast Charlie htlc and use preimage to
get money immediately, Alice blacklists Charlie's fidelity bond. Bob:
does nothing, already has his privkey.

==== Retaliation as DOS-resistance ====

In some situations (e.g. step 8.) if one maker in the coinswap route is
the victim of a DOS they will retaliate by DOSing the previous maker in
the route. This may seem unnecessary and unfair (after all why waste
even more time and block space) but is actually the best way to resist
DOS because it produces a concrete cost every time a DOS happens.

== Analysis of deviations ==

This section discusses what happens if one party deviates from the
protocol by doing something else, for example broadcasting a htlc
contract tx when they shouldnt have.

The party name refers to what that party does, followed by other party's
reactions to it.
e.g. Party1: does a thing, Party2/Party3: does a thing in reaction

If multiple deviations are possible in a step then they are numbered
e.g. A1 A2 A2 etc

0-2. Alice/Bob/Charlie: nothing else is possible except following the
protocol or aborting
3. Alice: broadcasts one or more of the A htlc txes. Bob/Charlie/Dennis:
do nothing, they havent lost any time or money.
4-6. Bob/Charlie: nothing else is possible except following the protocol
or aborting.
7. Bob: broadcasts one or more of the B htlc txes, Alice: broadcasts all
her own A htlc txes and waits for the timeout to get her money back.
Charlie: do nothing
8. Charlie: nothing else is possible except following the protocol or
aborting.
9. Alice: broadcasts one or more of the A htlc txes. Bob: broadcasts all
his own A htlc txes and waits for the timeout.
A. same as 8.
B. Charlie: broadcasts one or more of the C htlc txes, Alice/Bob:
broadcasts all their own htlc txes and waits for the timeout to get
their money back.
C-E1. Alice: broadcasts all of C htlc txes and uses her knowledge of the
preimage hash to take the money immediately. Charlie: broadcasts
all of B htlc txes and reading the hash value from the blockchain,
uses it to take the money from B htlc immediately. Bob: broadcasts
all of A htlc txes, and reading hash from the blockchain, uses it
to take the money from A htlc immediately.
C-E2. Alice: broadcast her own A htlc txes, and after a timeout take the
money. Bob: broadcast his own B htlc txes and after the timeout
take their money. Charlie: broadcast his own C htlc txes and after
the timeout take their money.
F1. Bob: broadcast one or more of A htcl txes and use the hash preimage
to get the money immediately. He already knows both privkeys of the
multisig so this is pointless and just damages privacy and wastes
miner fees. Alice: blacklist Bob's fidelity bond.
F2. Bob: broadcast one or more of the C htlc txes. Charlie: use preimage
to get his money immediately. Bob's actions were pointless. Alice:
cant tell whether Bob or Charlie actually broadcasted, so blacklist
both fidelity bonds.
G1. Charlie: broadcast one or more of B htcl txes and use the hash
preimage to get the money immediately. He already knows both
privkeys of the multisig so this is pointless and just damages
privacy and wastes miner fees. Alice: cant tell whether Bob or
Charlie actually broadcasted, so blacklist both fidelity bonds.
G2. Charlie: broadcast one or more of the A htlc txes. Alice: broadcast
the remaining A htlc txes and use preimage to get her money
immediately. Charlies's actions were pointless. Alice: blacklist
Charlie's fidelity bond.

The multisig outputs of the funding transactions can stay unspent
indefinitely. However the parties must always be watching the network
and ready to respond with their own sweep using a preimage. This is
because the other party still possesses a fully-signed contract tx. The
parties respond in the same way as in steps C-E1, F2 and G2. Alice's
reaction of blacklisting both fidelity bonds might not be the right way,
because one maker could use it to get another one blacklisted (as well
as themselves).

== Conclusion ==

This document describes the first version of the protocol which
implements multi-transaction Coinswap, routed Coinswap, fidelity bonds,
a liquidity market and private key handover. I describe the protocol and
also analyze aborts of the protocols and deviations from the protocol.

📅 Original date posted:2020-05-12 📝 Original message:Hello ...

2023-06-07T18:24:38Z

In reply to nevent1q…9kcl
_________________________

📅 Original date posted:2020-05-12
📝 Original message: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. While in the original coinswap
proposal an analyst of the chain would always see a funding transaction
followed closely in time by a success transaction, and this could be
used as a fingerprint.

On 11/05/2020 18:50, Ruben Somsen via bitcoin-dev wrote:
> Hi ZmnSCPxj,
>
> Thanks for your feedback :)
>
>> CoinSwap for privacy is practically a "cross" chain atomic swap with the same chain and token for both sides of the swap, see also this set of ideas: https://github.com/AdamISZ/CoinSwapCS/issues/53
>>
>> "Instead, Bob simply hands secretBob to Alice" is basically the same as private key turnover
>
> Thanks for the link. I will add it to the links at the bottom of the
> write-up, as I agree it's related. Do note there are a few key
> differences:
>
> - The swap is set up in an "asymmetric" way with only timelocks on one
> side, so on the other side the swap *never* expires
> - The timelocks are set up in such a way that the swap does not expire
> unless Alice starts the relative timelock countdown (the revoke
> transaction)
> - This relative timelock setup comes practically for free, because the
> asymmetry naturally requires that kind of setup

You could create an old-style coinswap scheme using relative timelocks
(with OP_CSV). The original proposal uses absolute timelocks but there's
no reason relative timelocks can't be used instead, as long as the party
who starts with knowledge of the preimage has a timelock further away in
the future.

Using relative timelocks and private key handover for old-style
coinswaps would give us the same two-transaction effect and the
corresponding efficiency and privacy gains.

Of course we still don't get the effect that the swap on the other side
never expires.

A fun fact is that the idea of private key handover was mentioned as
early as 2016 in the original Lightning Network paper. The bottom of
page 27 says: "Instead of disclosing the BR1a/BR1b signatures, it’s
also possible to just disclose the private keys to the counterparty.
This is more effective as described later in the key storage section".
Although it looks like nobody thought to apply it to coinswap or
realized the benefits.

Regards
CB

📅 Original date posted:2020-04-30 📝 Original message:Hello ...

2023-06-07T18:24:08Z

In reply to nevent1q…e6a2
_________________________

📅 Original date posted:2020-04-30
📝 Original message: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
>> using the input amounts. CoinSwap can be combined with something like
>> PayJoin or CoinJoinXT, which would genuinely break the CIOH, so such a
>> system wouldn't have this flaw either.
>>
>> For those reasons I've been thinking a CoinSwap system wouldn't need as
>> many mixdepths, maybe it could use two or even just one.
>
> Would the ZeroLink proposal of separating a receiving (pre-mix) wallet from a sending (post-mix) wallet apply, thus having two implicit mixdepths (the receiving mixdepth and the sending mixdepth)?
> Or would imposing the rule "all sends must be via CoinSwap" be sufficient (and follow the ZeroLink rule in spirit)?
>
>> If so, then it follows that multi-transaction CoinSwaps can be done by
>> having UTXOs come from the same mixdepth, as long as the inputs that
>> should be separate are not co-spent in the same transaction.
>
> 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-transaction CoinSwap where you do not merge any of your coins, it is immaterial if the sub-transactions come from the same mixdepth or not.
> And if you have to merge your coins (for instance, if you are a maker and your customer wants to get a UTXO that is larger than any you have on hand, you have to merge your coins), you just have to ensure they are in the same mixdepth.
>
> Of course, you *could* be proposing some other construct --- perhaps you have some relational entry which says "you cannot merge coin A and coin B" which allows you to merge A C D or B C E, but not A B?
> (I imagine this would make coin selection even harder, but I am not a mathematician and there may be some trivial solution to this.)
>
> Now --- if you have two coins that cannot be merged in the same onchain tx, what happens when you swap them in a multi-tx CoinSwap with somebody else?
> That somebody else does not know that information.
> Instead, that somebody else must always assume that any coins it got from the same CoinSwap operation must not be safely mergeable (though they can still be used in the same swap together).
>
> Coins received via receive addresses would also not be mergeable with any other coins, except coins to the same address (because coins in the same address already leak that they are owned by the same owner).

Yes I guess you're right. This part about mixdepths requires further
thought.

CoinSwap can be combined with some kind of CoinJoin (most likely
something similar to PayJoin or CoinJoinXT). That should help with the
reasoning about co-spending inputs and mixdepths, because other inputs
that are not owned by the taker will often be co-spent anyway.

Regarding coins which mustn't be co-spent being coinswapped to somebody
else, ideally that coinswap maker will receive coins from unrelated
takers too, so will merge their coins along with those as well. Also the
fact that a coinswap happened means there are two transactions between
the taker's-inputs-which-mustnt-be-merged and them actually being merged.

Great point on the receive addresses coins. Another use case of
mixdepths is to stop incoming payments from two different sources being
linked together.

>>> Assuming Alice is the taker, and Bob is the maker, then Alice might want a specific coin value (or set of such) that Bob does not have.
>>> In that case, Bob will have to split a UTXO it owns.
>>> We could constrain it so that Bob at least is not allowed to use the change from splitting for the same CoinSwap, e.g. if Bob has only 9 BTC and 1 BTC coins and Alice wants a 6 BTC / 3 BTC / 1 BTC split, then Bob cannot split its own 9 BTC coin then swap.
>>> Or in terms of mixdepths, Bob can split within a mixdepth but each outgoing UTXO in the same swap should be from different mixdepths.
>>
>> A good way to do it could be for Alice to tell Bob that she wants 10 BTC
>> and let Bob figure out on his own how to get that amount, based on the
>> amounts he already has. If Alice is making a payment she can provide
>> that amount too, but all the other output amounts can be up to Bob.
>
> This leaks to Bob whether Alice is making a payment or not; it would be better for the privacy of Alice for Alice to *always* mention *some* "payment amount", even if this is not actually a payment and Alice is just mixing for herself prior to storing in cold storage.
> And if Alice wants to use a single swap to pay to multiple targets at once, that implies Alice has to have the ability to indicate the outputs it wants to Bob, and it would imply as well that Alice has to obfuscate which of those outputs have amounts that actually *matter* (by always insisting on what the output amounts must be, rather than insisting on N output amounts and letting Bob handle the rest).
> (We *could* constrain it such that Alice can make only one payment per CoinSwap, so that Alice only gives one "target" amount and one "total" amount, but that implies even bigger blockspace utilization, sigh.)
>
> Otherwise, Bob can get information:
>
> * "Oh, Alice did not specify any of the outputs, just the total amount, all of my old coins are owned by Alice now."
> * "Oh, Alice specified an exact value for one of the outputs, that one is no longer owned by Alice but the rest are owned by Alice."
> * "Oh, Alice specified exact values for two of the outputs, those two are definitely no longer owned by Alice but the rest are owned by Alice."
>
> The conclusion here is either Alice never specifies any of the outputs --- in which case Alice cannot use a CoinSwap to pay directly to somebody else --- or Alice specifies all of them.
>
> Again, the maker might be an active surveillor, thus we should reduce information leaks to the maker as much as we can.

Yep great point.

A benefit of Alice not specifying any amounts is that Bob is able to
improve privacy and reduce costs by creating fewer change outputs. A
downside is that this leaks Alice's intentions (self-mix vs payment) to Bob.

A solution could be to add randomness. Have Alice randomly specify
payment amounts with some probability even if she is only self-mixing.

Although this doesn't solve everything, because Alice not specifying any
amounts implies self-mixing. But at least specifying some amounts
doesn't imply a payment.

>>
>> Bob would often still have to split a UTXO he owns, but see below about
>> breaking change address heuristics.
>>
>>> Of course, if a surveillor does solve the sparse subset sum, then the CoinSwap Protocol part looks exactly like a Bitcoin transaction, with a "main" paying output and a "change" output, and the same techniques that work with current Bitcoin txes work with "CoinSwap Protocol" virtual transactions.
>>> It seems to me that, in a system of makers and takers, even if the maker is really just paying the taker(s) to do CoinSwaps to mix back to itself, it should still "require" some output amount that really goes to itself, so that the maker at least does not differentiate between the case that the taker is paying to itself vs the case that the taker is paying someone else via a CoinSwap.
>>> That is, the protocol should still require that the taker specify some target desired amount, regardless of whether the taker wants to pay a specific value, or the taker wants to just mix its coins.
>>
>> If Bob needs to split a UTXO he'd do that with a change output. And
>> because we understand change detection heuristics we can intentionally
>> break them, for example if Bob's UTXO is on a p2sh-p2wpkh address and
>> the CoinSwap address is of that type too (because ECDSA-2P is being
>> used) then Bob could make his change output p2wpkh or p2pkh. Then anyone
>> using the script-type-heuristic would think that the CoinSwap address is
>> actually change and still belongs to Bob, and that the real change
>> address is actually the payment or CoinSwap address. i.e. the adversary
>> would assume that wallet software only uses one script type, in this
>> case it assumes that Bob's wallet is exclusively p2sh-p2wpkh.
>>
>>>> - Multi-transaction CoinSwaps aren't truly an example of a subset-sum
>>>> problem, but "sparse subset sum", a related and easier problem.
>>>> The way its normally formulated, subset sum is about finding a subset
>>>> that adds up to a target value. But in multi-transaction coinswap
>>>> there'd only be three or four CoinSwap outputs, so the problem is
>>>> finding just three or four integers in a big set that add up to the target.
>>>> You could think of it mathematically that the n-choose-k function is
>>>> near-polynomial when k is near 0 or near n, and the function is
>>>> exponential when k is near n/2.
>>>> A more promising way to build privacy is to create a situation where an
>>>> adversary would find a huge amount of false positives which are very
>>>> close the amount being sent. So even if the adversary has enough
>>>> computational power to iterate all the amounts it won't help them much
>>>> due to the huge number of false positives.
>>>>
>>>
>>> What are your thoughts on creating such possible situations?
>>> An idea is to require standard swap amounts, i.e. similar to the standard 100mBTC mixing bin of Wasabi.
>>> As well, one could randomly select some existing 1-input 1-output txes in the mempool and/or recent blocks, sum them, and swap for the same sum, to force at least one false positive, but the surveillor could protect against this by removing the earliest match (the one it saw in the mempool first, or onchain).
>>
>> I think we can get the false positive count up because the n-choose-k
>> function still gets quite large as k increases.
>>
>> We can make a simplified reasonable assumption that outputs on the
>> blockchain follow a lognormal distribution. An adversary trying to unmix
>> a 3-transaction CoinSwap would have to find the sum of every
>> 3-combination of the relevant outputs. For our case, the sum of three
>> lognormal distributions is another lognormal distribution with different
>> parameters, it's corresponding frequency distribution would get scaled
>> by n-choose-3. This frequency distribution is what the adversary would
>> find when searching, and that distribution would be quite tall because
>> of the scaling by n-choose-k. Suppose our CoinSwap is for 4 BTC then the
>> adversary would look at their frequency distribution at 4 BTC and find a
>> pretty big number, i.e. many other combinations of 3 outputs would add
>> up to 4 BTC just by chance. That is the false positive rate, and is our
>> anonymity set with respect to this attack.
>>
>> To work this out precisely we'd need to study the distribution of output
>> values on the blockchain today, and see how it behaves when summed
>> together. But the lognormal distribution assumption is probably not too
>> far from the truth, as it appears all the time in economics and finance,
>> and there is a clear justification for why. And the scaling by
>> n-choose-k would still hold.
>
> Okay, from what little I understand it seems that "even if sparse subset sum is easier than subset sum, it is still hard, so it probably will not matter in practice", would that be a fair takeaway?

Not exactly. Here's another summary:

Suppose Alice has V bitcoins and mixes them with multi-transaction
CoinSwap, she receives transactions with amounts (w_0, w_1, w_2....)
which add up to V.

Privacy relying on the (sparse) subset sum problem works by making it
_computationally infeasible_ for an adversary to search the entire
blockchain for sets of transactions (w_0, w_1, w_2....) which add up to
V. I believe aiming for this kind of privacy isn't practical due to
block space considerations and others.

Privacy relying on false positives does not make any search
computationally infeasible, it works by having a large number of other
sets of transactions (w_0, w_1, w_2....) which add up to V just by
chance. Then the transactions received by Alice's will have a big crowd
to hide in. I believe this is practical because the numbers are
proportional to the n-choose-k function which can still be very large.

Regards
CB

📅 Original date posted:2020-04-29 📝 Original message:Hello ...

2023-06-07T18:24:06Z

In reply to nevent1q…xq6v
_________________________

📅 Original date posted:2020-04-29
📝 Original message: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-coinjoins were involved that benefit
would be lost. So it would be better if it didn't happen.

> However, this requires us to retain compatibility with the JoinMarket wallet structure, which is divided into mixdepths, with the rule that UTXOs in different mixdepths cannot be spent together in the same onchain UTXO (to move across mixdepths you have to do a send, and sending out is always done by a single CoinJoin round with multiple makers).
> I am uncertain what is the best way to handle multitransaction when considering the mixdepth system.
> My instinct is that if you are doing multitransaction (whether as taker or maker) then each transaction in the swap *has to* come from a different mixdepth.
> The issue here is:
>
> * If all the UTXOs in the multitransaction swap come from the same mixdepth, then a surveillor who is monitoring that mixdepth gets a good hint in solving the sparse subset sum problem.
> * On the other hand, if all the UTXOs in the multitransaction swap come from different mixdepths, then a surveillor who has solved the sparse subset sum problem now has the hint that the different mixdepths are really owned by the same JoinMarket user.
>
> I am uncertain which tradeoff is better here, though I am inclined to think the latter is better.

JoinMarket has many mixdepths (5 by default) because it's
equal-output-coinjoins easily leak change addresses. CoinSwap
transactions don't have this flaw because they're steganographic. Such a
system could also be coded to intentionally break the weaker change
output heuristics
(https://en.bitcoin.it/wiki/Privacy#Change_address_detection).

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
using the input amounts. CoinSwap can be combined with something like
PayJoin or CoinJoinXT, which would genuinely break the CIOH, so such a
system wouldn't have this flaw either.

For those reasons I've been thinking a CoinSwap system wouldn't need as
many mixdepths, maybe it could use two or even just one.

If so, then it follows that multi-transaction CoinSwaps can be done by
having UTXOs come from the same mixdepth, as long as the inputs that
should be separate are not co-spent in the same transaction.

Remember that a passive surveillor of the blockchain doesn't see
mixdepths at all, they see addresses and transactions, and must use
heuristics to try to cluster them together. We can break these heuristics.

> Attempting to completely detach a market-for-CoinSwap from JoinMarket seems to be impossible to my mind: the protocols are known, implementations open, and someone will inevitably write code for a single piece of software that can operate as both a JoinMarket maker *and* a maker for a market-for-CoinSwap (to increase their market, so to speak), so it might be better to just add CoinSwap to JoinMarket in the first place.

Someone who has the ability to write such code should also have the
awareness to realize that mixing equal-output-coinjoins with coinswaps
damages the privacy because it breaks the steganography of coinswaps.

Also, because CoinSwap is better than equal-output CoinJoin in almost
every way, we can expect users (who are takers) to stop using JoinMarket
and switch over to CoinSwap if the software becomes mature. So such a
JoinMarket maker won't get many customers, and so there wouldn't be much
point writing such maker code.

But for sure it would be good to reuse code in any eventual
implementation. Indeed Waxwing's implementation did:
https://github.com/AdamISZ/CoinSwapCS

> Assuming Alice is the taker, and Bob is the maker, then Alice might want a specific coin value (or set of such) that Bob does not have.
> In that case, Bob will have to split a UTXO it owns.
>
> We could constrain it so that Bob at least is not allowed to use the change from splitting for the same CoinSwap, e.g. if Bob has only 9 BTC and 1 BTC coins and Alice wants a 6 BTC / 3 BTC / 1 BTC split, then Bob cannot split its own 9 BTC coin then swap.
> Or in terms of mixdepths, Bob can split within a mixdepth but each outgoing UTXO in the same swap should be from different mixdepths.

A good way to do it could be for Alice to tell Bob that she wants 10 BTC
and let Bob figure out on his own how to get that amount, based on the
amounts he already has. If Alice is making a payment she can provide
that amount too, but all the other output amounts can be up to Bob.

Bob would often still have to split a UTXO he owns, but see below about
breaking change address heuristics.

> Of course, if a surveillor ***does*** solve the sparse subset sum, then the CoinSwap Protocol part looks exactly like a Bitcoin transaction, with a "main" paying output and a "change" output, and the same techniques that work with current Bitcoin txes work with "CoinSwap Protocol" virtual transactions.
>
> It seems to me that, in a system of makers and takers, even if the maker is really just paying the taker(s) to do CoinSwaps to mix back to itself, it should still "require" some output amount that really goes to itself, so that the maker at least does not differentiate between the case that the taker is paying to itself vs the case that the taker is paying someone else via a CoinSwap.
> That is, the protocol should still require that the taker specify *some* target desired amount, regardless of whether the taker wants to pay a specific value, or the taker wants to just mix its coins.

If Bob needs to split a UTXO he'd do that with a change output. And
because we understand change detection heuristics we can intentionally
break them, for example if Bob's UTXO is on a p2sh-p2wpkh address and
the CoinSwap address is of that type too (because ECDSA-2P is being
used) then Bob could make his change output p2wpkh or p2pkh. Then anyone
using the script-type-heuristic would think that the CoinSwap address is
actually change and still belongs to Bob, and that the real change
address is actually the payment or CoinSwap address. i.e. the adversary
would assume that wallet software only uses one script type, in this
case it assumes that Bob's wallet is exclusively p2sh-p2wpkh.

>
>> - Multi-transaction CoinSwaps aren't truly an example of a subset-sum
>> problem, but "sparse subset sum", a related and easier problem.
>>
>> The way its normally formulated, subset sum is about finding a subset
>> that adds up to a target value. But in multi-transaction coinswap
>> there'd only be three or four CoinSwap outputs, so the problem is
>> finding just three or four integers in a big set that add up to the target.
>>
>> You could think of it mathematically that the n-choose-k function is
>> near-polynomial when k is near 0 or near n, and the function is
>> exponential when k is near n/2.
>>
>> A more promising way to build privacy is to create a situation where an
>> adversary would find a huge amount of false positives which are very
>> close the amount being sent. So even if the adversary has enough
>> computational power to iterate all the amounts it won't help them much
>> due to the huge number of false positives.
>
> What are your thoughts on creating such possible situations?
>
> An idea is to require standard swap amounts, i.e. similar to the standard 100mBTC mixing bin of Wasabi.
>
> As well, one could randomly select some existing 1-input 1-output txes in the mempool and/or recent blocks, sum them, and swap for the same sum, to force at least one false positive, but the surveillor could protect against this by removing the earliest match (the one it saw in the mempool first, or onchain).

I think we can get the false positive count up because the n-choose-k
function still gets quite large as k increases.

We can make a simplified reasonable assumption that outputs on the
blockchain follow a lognormal distribution. An adversary trying to unmix
a 3-transaction CoinSwap would have to find the sum of every
3-combination of the relevant outputs. For our case, the sum of three
lognormal distributions is another lognormal distribution with different
parameters, it's corresponding frequency distribution would get scaled
by n-choose-3. This frequency distribution is what the adversary would
find when searching, and that distribution would be quite tall because
of the scaling by n-choose-k. Suppose our CoinSwap is for 4 BTC then the
adversary would look at their frequency distribution at 4 BTC and find a
pretty big number, i.e. many other combinations of 3 outputs would add
up to 4 BTC just by chance. That is the false positive rate, and is our
anonymity set with respect to this attack.

To work this out precisely we'd need to study the distribution of output
values on the blockchain today, and see how it behaves when summed
together. But the lognormal distribution assumption is probably not too
far from the truth, as it appears all the time in economics and finance,
and there is a clear justification for why. And the scaling by
n-choose-k would still hold.

Along with that, some output amounts have very few significant figures
(e.g. 1 BTC, 0.1 BTC, 0.01 BTC), presumably because the user types just
one number on their keyboard when creating a transaction. We can use
that fact to add a bit of privacy by occasionally making one of our
outputs also be rounded like that.

📅 Original date posted:2020-04-28 📝 Original message:On ...

2023-06-07T18:24:05Z

In reply to nevent1q…azwt
_________________________

📅 Original date posted:2020-04-28
📝 Original message: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.mcgill.ca/~lyepre/pdf/assignment2-solutions/subsetSumNPCompleteness.pdf )?
>> That is, a pair of individuals with a set of UTXOs that both add up to similar if not equal value perform a swap of similar-(total)value sets. In this way the values of the UTXOs can be broken up essentially at random (following some nominal distribution so that it doesn't stand out; e.g. https://en.wikipedia.org/wiki/Benford%27s_law), but swapped in conjunction and decorrelated by using different keys + randomized locktimes.
>
> There are a number of issues to simply modeling this to the subset-sum problem.
>
> * There is a practical limit to the number of UTXOs you would be willing to receive in the swap.
> * Every UTXO you receive increases the potential fee you have to pay to spend them, meaning you would strongly dislike receiving 100 UTXOs that sum up to 1mBTC.
> * Thus, a practical blockchain analyst can bound the size of the sets involved, and the problem becomes less than NP in practice.
> * If you have a single UTXO and split it, then swap, anyone looking at the history can conjecture that the split involved is part of a CoinSwap.
> * The split is now a hint on how the subset sums can be tried.
> * If after the CoinSwap you spend the UTXOs you received in a single transaction, then you just published the solution to the subset sum for your adversary.
> * This ties in even further to the "practical limit on the number of UTXOs".
> * Because it is not safe to spend the UTXOs from a single CoinSwap together, you want to have fewer, larger UTXOs for more flexibility in spending later.
>
> I believe belcher and waxwing and nopara73 have been working far longer on privacy tech, and you should try to get in contact with them as well, they may know of other issues (or solutions to the above problems).
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Hello list,

A couple of thoughts on multi-transaction coinswaps:

* Users should never split up a single UTXO before doing a coinswap,
instead they should send the one UTXO to a coinswap address and get back
multiple UTXOs.

For example, this 1-to-3 TXO coinswap (The symbol ----> means bitcoin
transaction).

AliceA (10 BTC) ----> CoinSwap AddressA ----> BobA (10 BTC)

BobB (3 BTC) ----> CoinSwap AddressB ----> AliceB (6 BTC)
BobC (2 BTC) ----> CoinSwap AddressC ----> AliceC (3 BTC)
BobD (5 BTC) ----> CoinSwap AddressD ----> AliceD (1 BTC)

Note that the Bob-to-Alice set of transactions add up to 10 BTC, the
entire CoinSwap is swapping the same amount.

Or written another way:

Alice TXO (10 BTC) ----> Coinswap Protocol ----> Alice TXO1 (6 BTC)
----> Alice TXO2 (3 BTC)
----> Alice TXO3 (1 BTC)

This kind of thing could also be used for consolidation of many UTXOs
without necessarily leaking information that the same person owns them.
For example, if Alice owns 5 UTXOs:

Alice TXO1 ----> Coinswap Protocol ----> Alice TXO
Alice TXO2 ---->
Alice TXO3 ---->
Alice TXO4 ---->
Alice TXO5 ---->

* It's helpful if any CoinSwap app is actually used for spending rather
than just mixing back to yourself. That will help avoid the problem of
users inadvertently co-spending all their coinswap outputs in the same
transaction.
An example of Alice paying for a VPN anonymously:

Alice TXO (10 BTC) ---> Coinswap Protocol ---> VPN Payment (0.1 BTC)
---> Change1 (6 BTC)
---> Change2 (3 BTC)
---> Change3 (0.9 BTC)

In this case Alice will never accidentally merge all her TXOs together,
because the VPN Payment TXO doesn't belong to her. Also this could
improve privacy because unlike in normal transaction the VPN provider
might not be able to figure out the lower bound of Alice's balance (10
BTC in this case).

* Multi-transaction CoinSwaps aren't truly an example of a subset-sum
problem, but "sparse subset sum", a related and easier problem.

The way its normally formulated, subset sum is about finding a subset
that adds up to a target value. But in multi-transaction coinswap
there'd only be three or four CoinSwap outputs, so the problem is
finding just three or four integers in a big set that add up to the target.

You could think of it mathematically that the n-choose-k function is
near-polynomial when k is near 0 or near n, and the function is
exponential when k is near n/2.

A more promising way to build privacy is to create a situation where an
adversary would find a huge amount of false positives which are very
close the amount being sent. So even if the adversary has enough
computational power to iterate all the amounts it won't help them much
due to the huge number of false positives.

Regards
CB

📅 Original date posted:2019-08-07 📝 Original message:These ...

2023-06-07T18:19:57Z

In reply to nevent1q…4vlu
_________________________

📅 Original date posted:2019-08-07
📝 Original message: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 new wallets to be created and hodlers must trust the
wallets enough to move their coins and hold them there for a long time.

Requiring fidelity bond TXOs to be held in hot wallets can also be
beaten as a scheme for stopping renting, because the rentee can put
their coin private keys on an always-on raspberry pi which is connected
to the maker's computer and constantly ready to give out signatures. The
coins would be in hot wallets yet still be rented out. As above the
raspberry pi setup would be much more of a hassle than copypasting a
signature into a website, so it could still be worth doing.

I wonder if there's a cryptographic way to prove that muSig and 2P-ECDSA
have not been used to create a certain pubkey/signature.

On 06/08/2019 22:37, Dmitry Petukhov wrote:
> Unfortunately, both described schemes fail the same way as
> 'require TXOs to be consolidated by the owner', by the fact that with
> muSig, shared ownership of TXO is possible, as explained by ZmnSCPxj in
> [1]. 2P-ECDSA is also possible, just more complex, so just saying 'ban
> musig for the bonds' is not the answer, I believe.
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.html
>
> В Wed, 7 Aug 2019 01:55:41 +0500
> Dmitry Petukhov <dp at simplexum.com> wrote:
>
>> В Mon, 5 Aug 2019 20:04:26 +0100
>> Chris Belcher <belcher at riseup.net> wrote:
>>
>>> So what's needed is a way to make renting out TXOs impossible or
>>> very difficult.
>>
>> You can make renting the TXOs risky for the attacker. Make it so that
>> the entity that rented out the TXO can revoke the participation of
>> said TXO in the market, by publishing some special signature. That
>> act of revocation can also mean revocation of all other TXOs that
>> were used in a bond alongside it. This way, any entity that wants to
>> spoil an attacker's consolidation via rent, can rent out its TXO to
>> the attacker, and then revoke it, spoiling the whole package the
>> attacker have consolidated.
>>
>> There may be other way to impose penalties.
>>
>> For example, all locked TXO may be required to be spendable by *any*
>> key that controls any TXO in the 'bond TXO package'. I think this
>> should be possible with taproot - you will have to publish a taproot
>> trees for your locked TXOs (say, N of them), and the tree for each TXO
>> will have N leaves, each leaf will specify a condition "spendable by
>> the key N". This way, if I give you my TXO to include it in a bond by
>> locking it, you also need to make your other TXOs in a bond spendable
>> by me.
>>
>> For both scenarios to work for the attacker, there's need to be an
>> off-chain contractual relationship between the parties. Otherwise the
>> entity that rents out the TXOs can spoil or just confiscate the bond
>> of the entity that rented them, without reprecussions.
>
>

📅 Original date posted:2019-08-05 📝 Original message:On ...

2023-06-07T18:19:55Z

In reply to nevent1q…4mzp
_________________________

📅 Original date posted:2019-08-05
📝 Original message:On 02/08/2019 10:50, Dmitry Petukhov wrote:
> В Fri, 2 Aug 2019 10:21:57 +0100
> Chris Belcher <belcher at riseup.net> 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
>
> But if the entity that rented the coins, makes a profit using this coins
> from the maker opertion, and it makes the same or higher amount than
> it paid in rent, is it a sacrifice ? Given that the aim was to not make
> a profit in the first place, just increase deanonymization
> capabilities ?

Yes you're right. I should correct myself: Running a maker under the
proposal doesn't require a sacrifice of value, in fact you actually make
money doing it.

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 entities who run multiple maker bots, then we can say that
running a dishonest maker operation requires a sacrifice of fee income,
because someone doing that would earn more money if they ran an honest
maker instead. This happens because of the quadratic V^2 term in the
formula calculating the fidelity bond value, which provides this
incentive for lumping together fidelity bonds. This V^2 is probably the
most important part for privacy.

The V^2 term also creates a bad incentive where multiple people might
choose to pool together their bitcoin hoard into one maker bot so that
each can earn a higher fee income. This can be done by renting out TXOs
signatures as you've said.

So what's needed is a way to make renting out TXOs impossible or very
difficult. We can note that fidelity bonds made of rented TXOs will be
made up of a large number of relatively small valued TXOs, so one
amelioration is to cap the number of TXOs that can be used in one
fidelity bond. This could be worked around by honest makers because they
can consolidate TXOs on the blockchain, which rented TXO owners can't do
because the TXOs are owned by different people.

Another way is to require the bond signature proofs to involve the
one-time taker identifier, and so be different every time. This
basically requires fidelity bond privkeys to be online in hot wallets,
and so should massively increase the difficulty of renting TXOs because
the maker and the TXO owner need to be in constant real-time communication.

Thoughts?

CB

📅 Original date posted:2019-08-06 📝 Original message:On ...

2023-06-07T18:19:55Z

In reply to nevent1q…uta9
_________________________

📅 Original date posted:2019-08-06
📝 Original message: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 entities who run multiple maker bots, then we can say that
>> running a dishonest maker operation requires a sacrifice of fee income,
>> because someone doing that would earn more money if they ran an honest
>> maker instead. This happens because of the quadratic V^2 term in the
>> formula calculating the fidelity bond value, which provides this
>> incentive for lumping together fidelity bonds. This V^2 is probably the
>> most important part for privacy.
>
> As established above, there will emerge a market to lock coins, so these locks
> will be readily available without having to buy them. Even with V^2 there is no
> reason to amass more coins beyond a certain point. Running the biggest 5 V^2
> scores should be pretty solid to get in on many coin joins.

We can be much more exact than saying makers get in on "many" coins. The
supporting document "Financial mathematics of JoinMarket fidelity bonds"
contains calculations for exactly this:
https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#sybil-attacks-from-enemies-within

The document finds that with realistic real-world data, the makers with
the top 5 most valuable bonds will be chosen 48% of the time. So
approximately half:half success for one coinjoin. This isn't enough to
deanonymize every single coinjoin. For example, the tumbler script by
default makes around 16 transactions so the odds of a successful sybil
attack is (0.48)^16 = 8 parts per million, with the success probability
reducing exponentially after each additional coinjoin.

>> Another way is to require the bond signature proofs to involve the
>> one-time taker identifier, and so be different every time. This
>> basically requires fidelity bond privkeys to be online in hot wallets,
>> and so should massively increase the difficulty of renting TXOs because
>> the maker and the TXO owner need to be in constant real-time communication.
>
> Requiring the bond to reside on a hot wallet would be a massive disadvantage.

Hopefully it won't come to that and we can invent some other way to stop
renting TXOs. But if that's the only way then we'd have to code it in
order to protect the interests of takers.

The most dangerous source of rented TXOs seems to be the coin age form
of fidelity bond. Hodlers could have coins already in a hardware wallet
or cold storage and just sign proofs renting their UTXOs to earn an
extra income without changing their setup at all. Bonds from OP_CLTV and
OP_RETURN burned coins seems to me a much less likely source of rented TXOs.

Because of that, it seems to me only coin age fidelity bonds would be
required to be on hot wallets.

Another option worth considering is the have a separate lower interest
rate for coin age bonds compared to OP_CLTV bonds, this would reflect
the lower sacrifice for coin age (past sacrifices must be worth less
than future sacrifices, because of risk and uncertainty of the unknown
future, as well as the risk of rented UTXOs)

> No matter how you look at the whole problem of sibyl attacks, the honest maker
> will have operational costs and gain fees and the sibyl attacker will have the
> same plus profit from the deanonymization. As long as makers hunt marginal
> profits, the sibyl attacker having the higher margin from deanonymization will
> always win. The fidelity bonds would make this even worse, as increased
> complexity and entry cost would not favor more makers but less even before the
> centralization incentive mentioned above (V^2). To say that old holders have
> bitcoins laying around that they can use for such bonds is a fallacy as they
> could just as well rent them out on a bonds market.

I think this is absolutely wrong, because sybil attackers give up some
fee income. Here is a worked example:

Let's say the sybil attacker is operating the top 5 most valuable maker
bots. If this attacker has X coins they would split them equally into 5,
so each maker has X/5 coins and their bond is worth (X^5)^2 = X^2/25,
with a total of 5 bots the fee income would be proportional to 5*X^2/25
= X^2/5. However if an honest maker had X coins they could create a
single bond which would be worth simply X^2 with a fee income
proportional to X^2. So the honest maker has a fee income higher by a
factor of 5 than the sybil attacker. The sybil attacker must take a 5x
hit to their fee income in order to sybil attack. This is the crucial
effect of the V^2 term.

The V^2 term is important, it just has the downside of incentivizing
renting of coins. If we can make that impossible then the problem would
go away.

> How about turning this upside down and shift the incentives from being taker to
> being maker by introducing a mandatory fee? If each join costs 1% per maker,
> people would initially gasp and reject to update to that version but those who
> do, will do to become makers, increasing the maker count massively and
> eventually most people in frequent need of joining will also become makers to
> offset the costs of being takers.
>
> With these changed rules again the sibyl attackers would still have their
> competitive edge and would flood the market with even more cheap offers but now
> everybody would have an incentive to do the same and as makers have to have the
> UTXOs, it's not free to sibyl attack already.
>

Apart from the inability of developers to enforce any kind of price, I
don't think this scheme would fix the sybil attack problem, because a
sybil attacker still gets a higher gain (deanonymization + fees)
compared to honest makers (who earn just fees)

📅 Original date posted:2019-08-02 📝 Original message:On ...

2023-06-07T18:19:54Z

In reply to nevent1q…exed
_________________________

📅 Original date posted:2019-08-02
📝 Original message:On 31/07/2019 16:50, Dmitry Petukhov wrote:
> В Tue, 30 Jul 2019 22:39:14 +0100
> Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> 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 makers to use all their fidelity bond coins with just
>> one maker, not spread them out over many makers.
>
> The attacker derives additional value from the use of
> locked utxo - the deanonimyzation capabilities.
>
> An entity M can use all of its locked coins to run a maker, and then
> earn value X. It will also incur some operational expenses in the course
> of running the maker, so the profit will be less than X.
>
> If these locked coins are given to the attacker A as a package, an
> attacker can derive a value of X+D where D is a value of increased
> deanonymization capabilities for an attacker. Operational expenses
> for an attacker are the same as before (without timelocked bonds),
> because they need to operate a lot of makers either way.
>
> If M is profit-driven and non-ideological, it can rent out all of its
> coins to A as a package, for the price X, and get the same value without
> running a maker and dedicating any resources and time to it, not
> incurring any operatinal expenses (thus having a bigger profit in the
> end).
>
> Attacker A will run a maker with M's coins, get profit X, pay X to M,
> get increased deanonymization capabilities.
>
> If renting out of utxo is done in a way that the owner always gets X
> after the lock expires, the operation will be riskless for the owner.
> The attacker will need to lock amount X along with owner's coins, but
> hopefully makes X back by running a maker operation.
>
> The price for renting out the coins will be determined on the size of
> the 'coin package', so it will not be feasible for the owners of the
> coins to rent them out separately.
>
> An attacker can even rent coins from several entities and combine them
> to create a more 'powerful' maker. If I understand correctly, such
> 'powerful' maker can have bigger profit than two less 'powerful'
> makers. It seems like a centralization risk to me.
>

There's a few different issues here.

Yes TXO fidelity bonds can be rented out, but that doesn't make a sybil
attack cheaper. 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. Because of the
maths and market forces the rent paid by the attacker should be about
the same as the cost of just buying the bitcoins and locking them.

Centralization and decentralization are not ends in themselves, the main
aim in JoinMarket is to improve privacy while keeping the other
properties of bitcoin (e.g. censorship resistance). A single maker can
never deanonoymize coinjoins no matter how valuable their bond is,
because takers always choose multiple makers, and all of them need to be
controlled by the sybil attacker for the attack to succeed. If a sybil
attacker splits up their fidelity bonds (rented or not) amongst multiple
maker bots then they reduce the value of their bonds because of the V^2
term.

Rented TXOs does destroy the effect of "A long-term holder probably
won't want to attack a system like JoinMarket which makes his own
investment coins more private and more fungible". However this is not
the main effect which would protect JoinMarket's privacy. The main
effect is the cost which for real-life numbers would be about 45-120
bitcoin sent to burner outputs.

Perhaps then rented TXOs is an argument against using coin age as a way
to create fidelity bonds. Hodlers would be far less likely to rent out
their coins if they have to specifically move them to a special
time-locked address. Another point is that for privacy reasons creators
of fidelity bonds should mix their coins before and after using them,
because those TXOs are revealed to the world. So it's likely that
fidelity bonds creators will need to install and run JoinMarket anyway.

📅 Original date posted:2019-07-25 📝 Original ...

2023-06-07T18:19:41Z

In reply to nevent1q…72hy
_________________________

📅 Original date posted:2019-07-25
📝 Original message: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 needed is a way to increase the cost of running in a maker in a
way that retains the anonymity and is attractive to long-term holders of
bitcoin. This can be done using time-locked addresses.

## Fidelity bonds

In bitcoin, a fidelity bond [3] is a mechanism where bitcoin value is
deliberately sacrificed to make a cryptographic identity expensive to
obtain. The sacrifice is done in a way that can be proven to a third party.

A way to create a fidelity bond is to burn an amount of bitcoins by
sending to a OP_RETURN output. Another kind is time-locked addresses
created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
sacrificed is time rather than money, but the two are related because of
the time-value-of-money.

Under this system, makers would sacrifice an amount of bitcoins and
publish a proof along with their coinjoin offers. Takers would choose
maker offers based on the sacrificed amount (as well as other factors),
knowing that a sybil attacker would also have to sacrifice a certain
amount of coins in order to unmix the taker's coinjoins. The sacrifice
would be an objective measurement that can't be faked and which can be
verified by anybody (just like, for example PoW mining)

Note that a long-term holder (or hodler) of bitcoins can buy time-locked
fidelity bonds essentially for free, assuming they never intended to
transact with their coins much anyway. A long-term holder probably won't
want to attack a system like JoinMarket which makes his own investment
coins more private and more fungible.

### Fidelity bonds in cold storage

The private keys of fidelity bonds can be kept offline. Signatures
potentially only need to be made when the timelock expires (every 6
months for example), or only once in the case of OP_RETURN burned coins.
This allows JoinMarket's sybil resistance to increase without the hot
wallet risk.

Burned coin signatures should still have a lifetime, in case the private
key associated with the IRC nick (which is online) is stolen, so that
the thief of that privkey can't impersonate the maker indefinitely. The
signature linking the burned coins and IRC nick could expire after
perhaps 6 months.

### Anonymity

Under this scheme makers would need to publish the transactions of their
fidelity bonds to the entire world. Those transactions could be subject
to blockchain analysis. So before makers do this they should make sure
their coins are anonymous (possibly by mixing with JoinMarket). Also if
they ever want to use their coins for something else apart from fidelity
bonds they should mix them.

### Value of a fidelity bond

See the other document (Financial mathematics of joinmarket fidelity
bonds)[4] for a formula expressing the value of a fidelity bond.

The value of a fidelity bond made by sending V bitcoins to a burner
address is:

V^2

The amount of bitcoins is squared to get the fidelity bond value. This
has the effect that economic-rational makers have a strong incentive to
lump up all their coin sacrifices together into one maker bot, not to
split it up over several bots.

The value of a fidelity bond made by locking up V bitcoins in a
time-locked address for time period T is:

V^2 (exp(rT) - 1)^2

To get an idea of the numbers, if we burn 2 btc then the value of the
fidelity bond is 4 BTC^2. If we lock up 100 BTC for one year, and have a
bitcoin interest rate r = 0.001 (0.1%) per year, then the value of that
fidelity bond is 0.01 BTC^2 which is the same as burning 0.1 BTC. That
is a relatively small valued bond. It can be increased by locking up
more bitcoins for longer (up to and including permanant locking via a
burner transaction).

## Taker algorithm for choosing makers

I suggest the following taker peer choosing algorithm: obtain the list
of offers and discard offers which the taker's user deems are too
expensive. One of the remaining offers is randomly chosen with weighting
determined by the fidelity bond value. Once an offer is chosen it is
removed from the list, and another offer is again randomly chosen, this
is repeated until the taker has chosen the desired number of
fidelity-bonded maker's offers.

Some people run makers not for profit but for their own privacy.
Therefore not all makers should be required to have bonds, because such
privacy-makers are useful to include in coinjoins too. We could have
taker allow say, an eighth (12.5%), of their coinjoin peers to be makers
without bonds. They can be chosen randomly from the orderbook without
any weighting based on fidelity bond values. Of course these are easy to
fake by an adversary so they dont contribute much to sybil resistance.

### Cost of sybil attacks

See the other document (Cost of sybil attacks) for discussion and
calculations on the sybil resistance given by the above maker-choosing
algorithm.

It can be calculated that the fidelity bond system dramatically
increases the cost of a sybil attack. With real-world data and realistic
assumptions we can calculate that a sybil attacker would need to lock up
30,000-80,000 bitcoins for 6 months, or send 45-120 bitcoins to burner
addresses to have a good chance of attacking the system by being all the
counterparties in everyone's coinjoin.

## Effect of fidelity bonds on CoinJoin fees

Someone might ask "why would anyone lock up coins for months or more,
let alone burn coins forever, just to run a maker bot". The only way
this would even happen is if makers can generate a higher income that
justifies the fidelity bond sacrifice. That higher income can only come
from taker's coinjoin fees (or possibly coinswap fees one day). We can
expect that makers with higher valued fidelity bonds will demand higher
coinjoin fees. So a big question is whether takers will accept paying
higher coinjoin fees. I think they will, because right now coinjoin fees
are only 10-1000 satoshi, and a far biggest cost of coinjoins is the
miner fee not the coinjoin fee. I'm pretty sure takers will recognize
that they get what they pay for, and that additional privacy is well
worth the cost. Any other takers reading this should definitely let me
know what they think.

## Technical ideas

JoinMarket's wallet could also create time-locked addresses. Locktimes
should be fixed to be midnight on the first day of each month, then each
public key corresponds to 12 addresses per year (1200 addresses per
century) which is very practical to all be monitored as watch-only
addresses. These wallets can be created offline and could safely hold
time-locked bitcoins.

The timelocked addresses public key can be used to sign an IRC nickname
proving that the nickname is the real owner of the TXO. OP_RETURN
outputs used for burning coins can include a pubkey hash used for the
same thing.

We don't want the cold storage keypairs to be held online. We can design
the system that the time-locked address keypair is held offline but it
signs another key pair which is held online. Every time the IRC bot
connects it can use this intermediate keypair to sign the IRC nickname
proving ownership. The signature from the time-locked address to the
intermediate keypair can be made to have an expiry date (for example 6
months). This all means that the time-locked bitcoins can be held
offline but still be used to prove ownership of an IRC nickname.

The existance of the UTXO of a time-locked coin can be proved by
revealing the TXID and vout, which full nodes can use to query the UTXO
set to check that the coin exists. SPV clients would need a merkle proof
as well. Burned coins and spent time-locked coins could have their
existence proved by sharing the transaction which created them along
with a block height and transaction position for an unpruned node, or a
merkle proof for a pruned node or SPV client. Note that from the point
of view of a pruned node, a merkle proof is a fully-verified proof of
existance of a transaction. It is not a proof with just SPV-security.

## Links / References
[1] https://github.com/JoinMarket-Org/joinmarket-clientserver
[2] https://github.com/JoinMarket-Org/joinmarket/issues/693
[3] https://en.bitcoin.it/wiki/Fidelity_bonds
[4] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
[5]
https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybil-attacks
[6] First ever mention of fidelity bonds I found. The idea is basically
invented by Peter Todd: https://bitcointalk.org/index.php?topic=134827.0
[7] Old idea for combining fidelity bonds with mixers:
https://bitcointalk.org/index.php?topic=172047.0
[8] Suggestion that is very close to the fidelity bonds idea. He talks
about requiring a deposit from makers, but nobody is able to come up
with a way to make such a deposit decentralized and trustless:
https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=1

📅 Original date posted:2018-02-08 📝 Original ...

2023-06-07T18:10:33Z

In reply to nevent1q…z3ql
_________________________

📅 Original date posted:2018-02-08
📝 Original message: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 infinite money. Bitcoin's security model requires that
most economic activity is backed by full nodes. The Electrum servers
must also be trusted with the user's privacy, as wallets send all their
bitcoin addresses to the server. Spying on wallets is not much more
complicated than simply grepping the server logs. Electrum wallets by
default also connect to servers using their own IP address, linking it
further to their revealed bitcoin addresses.

A way to avoid these problems is for users to run their own Electrum
server and connect their wallets only to it. But this requires
significant resource usage: the full unpruned blockchain, transaction
index and an extra address index, as well as more RAM and CPU usage
compared to just a full node. Servers are not well suited to being shut
down and started up again, they are typically always online.

Electrum servers store a database of every bitcoin address ever used,
which is inherently not scalable. This is resource-intensive and
therefore pushes users towards centralized solutions. An alternative way
would be to store only your own addresses and transactions.

Introducing Electrum Personal Server; an implementation of the Electrum
server protocol which fulfills the specific need of using the Electrum
UI with full node verification and privacy, but without the heavyweight
server backend, for a single user. It allows the user to benefit from
all of Bitcoin Core's resource-saving features like pruning, blocksonly
and disabled txindex. All of Electrum's feature-richness like hardware
wallet integration, multisignature wallets, offline signing, mnemonic
recovery phrases and so on can still be used, but backed by the user's
own full node.

An alpha version of Electrum Personal Server can be found on the
repository: https://github.com/chris-belcher/electrum-personal-server

Before using, the wallet user must configure Electrum Personal Server
with their master public key and those addresses are imported into
Bitcoin Core as watch-only. If the wallet contains historical
transactions then it must be rescanned. One of Electrum's motivating
features is "instant on", which is therefore traded away when using
Electrum Personal Server in return for full node verification and
privacy. Although if a brand new empty wallet is created there is no
need to rescan. A script like Electrum Personal Server is also well
suited to use private transaction broadcasting tech like dandelion or
broadcasting through tor.

Using Electrum with Electrum Personal Server is probably the most
resource-efficient way right now to use a hardware wallet connected to
your own full node. People who make use of Blockstream Satellite could
use it to have an off-the-grid node connected to Electrum if that is
their preferred wallet. In the situation of a traveller staying a cheap
hostels, they could sync their node every couple of days to download
recent blocks and use Electrum. Hopefully this software can be part of
the plan to get full node wallets into the hands of as many people as
possible.

The same kind of ideas could be applied to other lightweight wallets.
For example a full nodes can run on smartphones with pruning and
blocksonly, then a similar script would allow the user to connect their
Samourai Wallet, Breadwallet or GreenAddress app to their own full node.

Further Reading:

* https://bitcointalk.org/index.php?topic=2664747.msg27179198
*
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html
* https://bitcointalk.org/index.php?topic=1634967.0;all

📅 Original date posted:2018-01-22 📝 Original message:This ...

2023-06-07T18:10:05Z

In reply to nevent1q…u8uu
_________________________

📅 Original date posted:2018-01-22
📝 Original message: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 anonymity set could be much higher, potentially including
almost every other on-chain transaction.

[1] https://bitcointalk.org/index.php?topic=321228.0
[2] https://github.com/AdamISZ/CoinSwapCS

On 23/01/18 00:30, Gregory Maxwell via bitcoin-dev wrote:
> Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main
> areas: efficiency and privacy. Efficiency because unexecuted forks of
> a script can avoid ever hitting the chain, and privacy because hiding
> unexecuted code leaves scripts indistinguishable to the extent that
> their only differences are in the unexecuted parts.
>
> As Mark Friedenbach and others have pointed out before it is almost
> always the case that interesting scripts have a logical top level
> branch which allows satisfaction of the contract with nothing other
> than a signature by all parties. Other branches would only be used
> where some participant is failing to cooperate. More strongly stated,
> I believe that _any_ contract with a fixed finite participant set
> upfront can be and should be represented as an OR between an N-of-N
> and whatever more complex contract you might want to represent.
>
> One point that comes up while talking about merkelized scripts is can
> we go about making fancier contract use cases as indistinguishable as
> possible from the most common and boring payments. Otherwise, if the
> anonymity set of fancy usage is only other fancy usage it may not be
> very large in practice. One suggestion has been that ordinary
> checksig-only scripts should include a dummy branch for the rest of
> the tree (e.g. a random value hash), making it look like there are
> potentially alternative rules when there aren't really. The negative
> side of this is an additional 32-byte overhead for the overwhelmingly
> common case which doesn't need it. I think the privacy gains are
> worth doing such a thing, but different people reason differently
> about these trade-offs.
>
> It turns out, however, that there is no need to make a trade-off. The
> special case of a top level "threshold-signature OR
> arbitrary-conditions" can be made indistinguishable from a normal
> one-party signature, with no overhead at all, with a special
> delegating CHECKSIG which I call Taproot.
>
> Let's say we want to create a coin that can be redeemed by either
> Alice && Bob or by CSV-timelock && Bob.
>
> Alice has public A, Bob has pubkey B.
>
> We compute the 2-of-2 aggregate key C = A + B. (Simplified; to
> protect against rogue key attacks you may want to use the MuSig key
> aggregation function [1])
>
> We form our timelock script S = "<timeout> OP_CSV OP_DROP B OP_CHECKSIGVERIFY"
>
> Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G.
>
> (This is the attack hardened pay-to-contract construction described in [2])
>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P].
>
> Now Alice and Bob-- assuming they are both online and agree about the
> resolution of their contract-- can jointly form a 2 of 2 signature for
> P, and spend as if it were a payment to a single party (one of them
> just needs to add H(C||S) to their private key).
>
> Alternatively, the Taproot consensus rules would allow this script to
> be satisfied by someone who provides the network with C (the original
> combined pubkey), S, and does whatever S requires-- e.g. passes the
> CSV check and provides Bob's signature. With this information the
> network can verify that C + H(C||S) == P.
>
> So in the all-sign case there is zero overhead; and no one can tell
> that the contract alternative exists. In the alternative redemption
> branch the only overhead is revealing the original combined pubkey
> and, of course, the existence of the contract is made public.
>
> This composes just fine with whatever other merkelized script system
> we might care to use, as the S can be whatever kind of data we want,
> including the root of some tree.
>
> My example shows 2-of-2 but it works the same for any number of
> participants (and with setup interaction any threshold of
> participants, so long as you don't mind an inability to tell which
> members signed off).
>
> The verification computational complexity of signature path is
> obviously the same as any other plain signature (since its
> indistinguishable). Verification of the branch redemption requires a
> hash and a multiplication with a constant point which is strictly more
> efficient than a signature verification and could be efficiently fused
> into batch signature validation.
>
> The nearest competitor to this idea that I can come up with would
> supporting a simple delegation where the output can be spent by the
> named key, or a spending transaction could provide a script along with
> a signature of that script by the named key, delegating control to the
> signed script. Before paying into that escrow Alice/Bob would
> construct this signature. This idea is equally efficient in the common
> case, but larger and slower to verify in the alternative spend case.
> Setting up the signature requires additional interaction between
> participants and the resulting signature must be durably stored and
> couldn't just be recomputed using single-party information.
>
> I believe this construction will allow the largest possible anonymity
> set for fixed party smart contracts by making them look like the
> simplest possible payments. It accomplishes this without any overhead
> in the common case, invoking any sketchy or impractical techniques,
> requiring extra rounds of interaction between contract participants,
> and without requiring the durable storage of other data.
>
>
> [1] https://eprint.iacr.org/2018/068
> [2] https://blockstream.com/sidechains.pdf Appendix A
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-03-05 📝 Original message:I ...

2023-06-07T17:57:02Z

In reply to nevent1q…t56t
_________________________

📅 Original date posted:2017-03-05
📝 Original message: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
forks. The situation between hard and soft forks is reversed.

In a fork between segwit-invalid and segwit-valid after a UASF, if the
segwit-valid chain ever ends up with more work then the segwit-invalid
chain will be annihilated in a big re-organization as
non-segwit-enforcing nodes move to the segwit-valid chain. The less-work
chain will simply cease to exist.

Only a miner that recodes their software can initiate such a fork,
because segwit transactions are non-standard and won't be relayed by
default.

A closer situation is the accidental fork created soon after the BIP66
soft fork. The fork lasted a few blocks and did not mine any
transactions except the coinbase. It was annihilated with a monetary
loss to any miner that took part.

Here is an argument for why chain fork is unlikely to last long or be
created by a rational self-interested miner, assuming the bitcoin
economic majority even slightly enforces the UASF.

Because the segwit-invalid coins can be annihilated in this way and
segwit-valid coins cannot, segwit-invalid coins are more risky to hold
as an asset, all else equal.

A more risky asset has a lower price, all else equal. Because investors
demand higher risk premiums for holding it and also short sellers may
sell down the price in the hopes of making a profit if it's value goes
to zero.

In cryptocurrencies like bitcoin, hashpower follows price. This is very
clear from historical trends and the underlying economic forces.

A lower-hashrate chain will eventually be overtaken in work by a
higher-hashrate chain.

Therefore, the segwit-invalid chain will be annihilated sooner or later
if the price of its coin is higher.

Of course as the old saying goes markets can stay irrational longer than
we can stay solvent, which is why I think UASF should only go ahead if
we're sure that a big part of the economic majority will enforce it.
This will make the value and liquidity of the segwit-invalid chain very
low and make the annihilating re-organization happen faster.
User-activated means it _must_ be done by the users of bitcoin.

📅 Original date posted:2017-02-16 📝 Original message:I ...

2023-06-07T17:56:24Z

In reply to nevent1q…47qt
_________________________

📅 Original date posted:2017-02-16
📝 Original message: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. Nonetheless this proposal still has many benefits and is well
worth working on.

==BIP37==

As a recap, probably the biggest and most problematic way that bip37 was
broken was by combining the partial wallet information from the bloom
filter with the transaction subgraph information from the blockchain

Suppose a wallet synchronizes it's history, if it spent a coin from its
address A, it must also also add the change address B to the bloom
filter, which is connected to A directly on transaction graph.

As an example, consider five typical transactions that consume one input
each and produce two outputs.
A, B, C, D, E refer to transactions. A1, A2, etc refer to addresses
within those transactions

-> C1
A1 -> B2 -> C2
-> B2 -> D1
-> D2 -> E1
-> E2

If a bip37 bloom filter matches addresses A1, B2, D2, E1 then it can be
seen that they form a "peel chain" [this terminology comes from
https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf]

-> X
A1 -> X -> X
-> B2 -> X
-> D2 -> E1
-> X

The same five transactions with non-matching addresses replaced by X.
The peel chain is visible, it's clear that B2, D2, E1 are change
addresses which belong to the same wallet as A1.

For a given false-positive rate fp and given length of peel chain C, the
odds of a false positive peel chain happening by chance is fp^C which
rapidly gets very small as the wallet makes more transactions (increases C).

If only one address was matched from the above group (for example B2)
then it likely to be a false positive by the fact that it doesn't make
any transactions to another address that also matches the bloom filter.
Another possibility is that the address is a payment output that the
wallet received but hasn't spent yet, but the wallet cant spend it
without adding the change address to the bloom filter and thus revealing
itself to the spy.

I believe the committed bloom filter proposal is vulnerability to this
same kind of attack because it still leaks information about which
addresses the wallet is interested in.

==Committed Bloom Filter Maths==

I'll try to analyze this now. I'll find the expectation value of the
number of transaction subgraphs in those blocks that appear just by
chance. If this expectation goes to zero, then the only transaction
subgraph left will be the real one that the wallet is actually
interested in. In that case it will be possible to spy on the wallet.

Assuming outputs have the same probability of being spent in each time
interval (i.e. they are spent in a Poisson process) This is
approximately true, see the graphs from
[https://letstalkbitcoin.com/blog/post/rise-of-the-zombie-bitcoins].
This means we can assign
a single probability P that an output is spent in each block.

Assume every transaction has one change address only and spending of
unconfirmed change doesn't happen (its more efficient to use RBF to add
additional outputs anyway)

Number of transactions per block = Q (about 1800 today)
Number of outputs per block = Z = 2*Q (approximately)
Length of peel chain = Number of transactions in wallet = C
Average time an output is unspent for = T (about 1 month, very roughly
estimating from the above blog post)
Probability an output being spent in any particular later block = P =
10minutes/T

Assume no false positive blocks
Say wallet downloaded two blocks and they are ordered by block height
The expected number of tx subgraphs between them, E(#G)
E(#G) = number of outputs created in block 1 that get spent in block 2
= Z*P

Say the wallet downloaded three blocks
Expected number of subgraphs going through them all
E(#G) = number of outputs created in block 1 get spent in block 2, that
create a change address which gets spent in block 3
= Z*P*P

Say the wallet downloaded C blocks
Expected number of tx subgraphs going through all the blocks by chance
E(#G) = Z*P^C
which gets small quickly as C goes up, because P < 1

Now drop the assumption about no false positive blocks.

Let the number of candidate blocks be D.
This is how many blocks the wallet scans, it's related to how far in the
past the wallet's keys was created. At one extreme wallet was created at
genesis block and so D = ~450000, at other extreme created now so D = 0.
Note that D = 0 must also imply C = 0

Expected number of false positive blocks downloaded = F = fp*D

In all these situations the blocks are sorted by block height

Suppose have C=2, F=1, and false one is in the middle.
I want to find E(#G|CF), the expected number of transaction subgraphs
that appear just by chance, given C and F.
E(#G|CF) = how many outputs which are created in block 1 get spent in
block 3
= Z*P

Same situation, but false one at the start instead of middle.
E(#G|CF) = how many outputs which are created in block 2 get spent in
block 3
= Z*P

Same situation but false one could be anywhere, result in the sum of the
probability for any false block position
E(#G|CF) = C(3, 1)*Z*P = 3*Z*P

where C() is the number of order-independent ways of choosing 1 element
out of a set of 3 elements, also known as the binomial coefficient

Now suppose C=3 and F=1
The same argument leads to
E(#G|CF) = C(4, 1)*Z*P^2 = 4*Z*P^2

Now suppose C=3 and F=2, with fp blocks at the end
E(#G|CF)
= how many outputs are created in block 1, are spent in block 2 and
change address spent in block 3
= Z*P^2

Same situation but fp blocks can be anywhere, add up all the possible
combinations of them within the rest
E(#G|CF) = C(5, 2)*Z*P^2 = 5*Z*P^2

With these same rules, its clear the general expression for any F and C
E(#G|CF) = C(F + C, F)*Z*P^(C - 1)

A more interesting value might be the time evolution of E(#G)
Let B be the blocks in the blockchain since the wallet creation date, as you
know it increases at an average rate of one every ten minutes

w = wallet transaction creation rate, expressed per-block
C = w * B
F = fp * B

J = average blocks between wallet transactions = 1440 (10 days)
w = 1/J

E(#G|B) = C((fp + w)*B, fp*B)*Z*P^(w*B - 1)

This goes to zero as B becomes big, although choosing very high values
of fp makes it go to zero slower.

This is only approximate maths, in actuality you cannot take the number
of false positive blocks to be fp*B, you have to sum over all blocks
weighted by probability. And outputs might not be spent in an exact
Poisson process so you cant just multiply by P each time. Plus if your
false positive rate is very high then some of your false positive blocks
will actually contain your real transactions, this analysis
double-counts them.

Using some reasonable values and plotting E(#G|B) against B can show how
quickly it drops and therefore leaves only the true transaction subgraph.

(note: in LibreOffice Math and Microsoft Excel the binomial coefficient
function is COMBIN)

==Notes==

*) The expected number of transaction subgraphs that happen by chance
goes to zero eventually as the blockchain steps ahead. Unless the fp
rate is very high (close to 1) and time between wallet transaction very
long, in which case the binomial coefficient term gets larger more
quicker than the exponential decay P^B term gets smaller.
*) fp rate doesn't help in most cases that much compared to the
exponential drop-off from time ticking ahead requiring more downloading
of blocks
*) its good for privacy if bitcoin outputs are spent more frequently so
P is higher, because that creates more transaction subgraphs in the
anonymity set.
*) its good for privacy if more outputs are made per block, although
still only linearly which is no match for the exponential reduction from
the P^B term.
*) its good for privacy to make less of your own transactions (increase
J and reduce w), for low-activity users the privacy of committed bloom
filters can be actually pretty good, for high-activity users who use
bitcoin's blockchain all the time it's not very good
*) For the reasonable values I tried for a once-a-month user with fp=1%,
their chance-transaction-subgraph-count drops below 1 in about eight months.
*) Because of the exponential nature, E(#G) goes from "billions of
billions" to "about 10" fairly quickly.

==Discussion of ways to mitigate this==

One way is to not use change outputs. This is unrealistic, doesn't match
people's behavior and money must be divisible.

A better way to mitigate this is to not leak the information that all
those blocks are interesting to the same wallet. Don't download all
blocks from the same archival node. If you download blocks from many
different nodes, it gives an incentive for surveillance startups to
create lots of sybil nodes they control and can then correlate together
block downloads with the wallet IP address. Many such startups are
already doing this today to try to detect the origin IP address of
broadcasted transactions.

Another solution could be to download a few blocks from different nodes
with new tor circuits used. This would delink the wallet IP address from
the downloads and would help a lot. This has the issue that tor is
slower (but still not as slow as downloading the entire blockchain)

Another way a wallet could be correlated with its block downloads is
timing correlations. At any one time only a certain number of peers
would be downloading blocks which narrows down which wallets are
downloading what. However even today Bitcoin Core downloads blocks in
parallel from many nodes so there's probably quite a large anonymity set
for lightweight wallets using committed bloom filters. Plus timing
correlation can be reduced simply by waiting longer. Wallets are not
sync'd from backup very often so it might be okay to wait.

Another way to improve privacy could be for the wallet to choose random
transaction subgraphs and download all the blocks related to them as well.

Wallet developers might choose to allow the user to configure their own
fp rate. This is probably not a good idea since the relationship between
fp rate and anonymity set is non-obvious. It might be better to ask the
user how often they expect to make transactions.

==Conclusion==

I think this committed bloom filter idea is very good and much better
than bip37, but for good privacy for when bitcoin is used often still
requires certain behavior namely downloading blocks
from many different peers with new tor circuits.

Note that I've been dealing with counting transaction subgraphs but
actually finding them from blocks might also be computationally
infeasible. Although a Bayesian approach worked very
well for similar transaction subgraph linking
[https://arxiv.org/pdf/1612.06747v3.pdf]

It would also be interesting to analyze what information a spy can get
if they are missing some blocks that the wallet downloaded.

For the long term, private and high-volume bitcoin use will be best
served by off-chain transactions. They will probably be a huge win just
because the large and public blockchain is such a non-private
way of doing things.

On 09/05/16 09:26, bfd--- via bitcoin-dev wrote:
> We introduce several concepts that rework the lightweight Bitcoin
> client model in a manner which is secure, efficient and privacy
> compatible.
>
> Thea properties of BIP37 SPV [0] are unfortunately not as strong as
> originally thought:
>
> * The expected privacy of the probabilistic nature of bloom
> filters does not exist [1][2], any user with a BIP37 SPV wallet
> should be operating under no expectation of privacy.
> Implementation flaws make this effect significantly worse, the
> behavior meaning that no matter how high the false positive
> rate (up to simply downloading the whole blocks verbatim) the
> intent of the client connection is recoverable.
>
> * Significant processing load is placed on nodes in the Bitcoin
> network by lightweight clients, a single syncing wallet causes
> (at the time of writing) 80GB of disk reads and a large amount
> of CPU time to be consumed processing this data. This carries
> significant denial of service risk [3], non-distinguishable
> clients can repeatedly request taxing blocks causing
> reprocessing on every request. Processed data is unique to every
> client, and can not be cached or made more efficient while
> staying within specification.
>
> * Wallet clients can not have strong consistency or security
> expectations, BIP37 merkle paths allow for a wallet to validate
> that an output was spendable at some point in time but does not
> prove that this output is not spent today.
>
> * Nodes in the network can denial of service attack all BIP37 SPV
> wallet clients by simply returning null filter results for
> requests, the wallet has no way of discerning if it has been
> lied to and may be made simply unaware that any payment has been
> made to them. Many nodes can be queried in a probabilistic manor
> but this increases the already heavy network load with little
> benefit.
>
>
>
> We propose a new concept which can work towards addressing these
> shortcomings.
>
>
> A Bloom Filter Digest is deterministically created of every block
> encompassing the inputs and outputs of the containing transactions,
> the filter parameters being tuned such that the filter is a small
> portion of the size of the total block data. To determine if a block
> has contents which may be interesting a second bloom filter of all
> relevant key material is created. A binary comparison between the two
> filters returns true if there is probably matching transactions, and
> false if there is certainly no matching transactions. Any matched
> blocks can be downloaded in full and processed for transactions which
> may be relevant.
>
> The BFD can be used verbatim in replacement of BIP37, where the filter
> can be cached between clients without needing to be recomputed. It can
> also be used by normal pruned nodes to do re-scans locally of their
> wallet without needing to have the block data available to scan, or
> without reading the entire block chain from disk.
>
> -
>
> For improved probabilistic security the bloom filters can be presented
> to lightweight clients by semi-trusted oracles. A client wallet makes
> an assumption that they trust a set, or subset of remote parties
> (wallet vendors, services) which all all sign the BFD for each block.
> The BFD can be downloaded from a single remote source, and the hash of
> the filters compared against others in the trust set. Agreement is a
> weak suggestion that the filter has not been tampered with, assuming
> that these parties are not conspiring to defraud the client.
>
> The oracles do not learn any additional information about the client
> wallet, the client can download the block data from either nodes on
> the network, HTTP services, NTTP, or any other out of band
> communication method that provides the privacy desired by the client.
>
> -
>
> The security model of the oracle bloom filter can be vastly improved
> by instead committing a hash of the BFD inside every block as a soft-
> fork consensus rule change. After this, every node in the network would
> build the filter and validate that the hash in the block is correct,
> then make a conscious choice discard it for space savings or cache the
> data to disk.
>
> With a commitment to the filter it becomes impossible to lie to
> lightweight clients by omission. Lightweight clients are provided with
> a block header, merkle path, and the BFD. Altering the BFD invalidates
> the merkle proof, it's validity is a strong indicator that the client
> has an unadulterated picture of the UTXO condition without needing to
> build one itself. A strong assurance that the hash of the BFD means
> that the filters can be downloaded out of band along with the block
> data at the leisure of the client, allowing for significantly greater
> privacy and taking load away from the P2P Bitcoin network.
>
> Committing the BFD is not a hard forking change, and does not require
> alterations to mining software so long as the coinbase transaction
> scriptSig is not included in the bloom filter.
>
>
> [0] https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki
> [1] https://eprint.iacr.org/2014/763.pdf
> [2] https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
> [3] https://github.com/petertodd/bloom-io-attack
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>