Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

[LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev]

I have but one point to make in a brief catch-up read over.

With the current protocol the fix to a network split is simple, the longest 
chain win. But with the moving checkpoint I'm proposing we have a problem if 
both chains began to differ more than N blocks ago, the forks are permanent. So 
we need an additional rule to ignore the moving checkpoint, a limit of X blocks:

It is not to be considered the longest chain, it is to be considered the 
longest chain with the most proof of work.

Regards,
LORD HIS EXCELLENCY JAMES HRMH




From: bitcoin-dev-boun...@lists.linuxfoundation.org 
 on behalf of Kenshiro [] via 
bitcoin-dev 
Sent: Friday, 2 August 2019 11:08 PM
To: Ethan Heilman ; Bitcoin Dev 

Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

Hi all,

Very good points. I did some clarifications in a private conversation, the new 
rule is making the moving checkpoint valid only if the difference in blocks 
between the main chain and the new fork is smaller than X blocks, like for 
example 3 days of blocks, so after a long network split everyone can finally 
follow the longest chain:

With the current protocol the fix to a network split is simple, the longest 
chain win. But with the moving checkpoint I'm proposing we have a problem if 
both chains began to differ more than N blocks ago, the forks are permanent. So 
we need an additional rule to ignore the moving checkpoint, a limit of X blocks:

If a node sees a fork longer than his main chain, and the fork has at least X 
blocks more than the main chain, then the node ignore the moving checkpoint 
rule, and it follows the fork, the longest chain.

So as an example, the moving checkpoint could be 24 hours of blocks, and the 
limit of X blocks, the blocks of 3 days.

So we have 2 possible situations to consider:

- 51% attack:  the blocks older than 24 hours are protected against a history 
rewrite during at least 3 days, in that time developers could release an 
emergency release with another mining algorithm to stop the attack.

- Network split: if the network split is older than N blocks, we have 2 
permanent forks (or chains), but in 3 days (or more) the blockchain heights 
will differ in more than X blocks (the blocks of 3 days) because there will be 
more miners in one chain than in the other so finally the loser chain will be 
abandoned and everyone will follow the longest chain.

It could be even more conservative, like 48 hours for the moving checkpoint and 
a block limit of 7 days of blocks.

Regards,




From: Ethan Heilman 
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] ; Bitcoin Dev 

Cc: Alistair Mann 
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

Attack 1:
I partition (i.e. eclipse) a bunch of nodes from the network this partition 
contains no mining power . I then mine 145 blocks for this partition. I don't 
even need 51% of the mining power because I'm not competing with any other 
miners. Under this rule this partition will hardfork from the network 
permanently. Under current rules this partition will be able to rejoin the 
network as the least weight chain will be orphaned.

Attack 2:
I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I feed 
it 145 blocks which fork off from the consensus chain. I have 24+24 hours to 
mine these 145 blocks so I should be able to do this with 25% of the current 
hash rate at the time the node went offline. Under your rule each of these 
offline-->online nodes I attack this way will hardfork themselves from the rest 
of the network.

I believe a moving-checkpoint rule as describe above would make Bitcoin more 
vulnerable to 51% attacks.

A safer rule would be if a node detects a fork with both sides of the split 
having  length > 144 blocks, it halts and requests user intervention to 
determine which chain to follow.  I don't think 144 blocks is a great number to 
use here as 24 hours is very short. I suspect you could improve the security of 
the rule by making the number of blocks a fork most reach to halt the network 
proportional to the difference in time between the timestamp in the block prior 
to the fork and the current time. I am **NOT** proposing Bitcoin adopt such a 
rule.

NXT has a fundamentally different security model as it uses Proof-of-stake 
rather than Proof-of-Work.

On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:
P.S.: To be clearer, in this example I set an N value of 144 blocks, which is 
approximately 24 hours.


From: Kenshiro [] mailto:tens...@hotmail.com>>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann mailto:a...@pectw.net>>; Bitcoin Protocol 
Discussion 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

>>> How would a 

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 51, Issue 3

[Steven Blinn via bitcoin-dev]

e clearer, in this example I set an N value of 144 blocks,
> which
> > is approximately 24 hours.
> >
> > --
> > *From:* Kenshiro [] 
> > *Sent:* Wednesday, July 31, 2019 16:40
> > *To:* Alistair Mann ; Bitcoin Protocol Discussion <
> > bitcoin-dev@lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> > protocol
> >
> > >>> How would a (potentially, state-sponsored) netsplit lasting longer
> > than N be
> > handled?
> >
> > It would be detected by the community much before reaching the reorg
> limit
> > of N blocks (it's 24 hours) so nodes could stop until the netsplit is
> > fixed.
> >
> > In the extreme case no one notice the network split during more than N
> > blocks (24 hours) and there are 2 permanent forks longer than N, nodes
> > from one branch could delete their local history so they would join the
> > other branch.
> >
> > Regards,
> >
> >
> > --
> > *From:* Alistair Mann 
> > *Sent:* Wednesday, July 31, 2019 15:59
> > *To:* Kenshiro [] ; Bitcoin Protocol Discussion <
> > bitcoin-dev@lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> > protocol
> >
> > On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:
> >
> > > I would like to propose that a "moving checkpoint" is added to the
> > Bitcoin
> > > protocol. It's a very simple rule already implemented in NXT coin:
> > >
> > > - A node will ignore any new block under nodeBlockHeight - N, so the
> > > blockchain becomes truly immutable after N blocks, even during a 51%
> > attack
> > > which thanks to the moving checkpoint can't rewrite history older than
> > the
> > > last N blocks.
> >
> > How would a (potentially, state-sponsored) netsplit lasting longer than N
> > be
> > handled?
> > --
> > Alistair Mann
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190802/9071fcc3/attachment.html
> >
>
> --
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 51, Issue 3
> **
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

[Kenshiro [] via bitcoin-dev]

Hi all,

Very good points. I did some clarifications in a private conversation, the new 
rule is making the moving checkpoint valid only if the difference in blocks 
between the main chain and the new fork is smaller than X blocks, like for 
example 3 days of blocks, so after a long network split everyone can finally 
follow the longest chain:

With the current protocol the fix to a network split is simple, the longest 
chain win. But with the moving checkpoint I'm proposing we have a problem if 
both chains began to differ more than N blocks ago, the forks are permanent. So 
we need an additional rule to ignore the moving checkpoint, a limit of X blocks:

If a node sees a fork longer than his main chain, and the fork has at least X 
blocks more than the main chain, then the node ignore the moving checkpoint 
rule, and it follows the fork, the longest chain.

So as an example, the moving checkpoint could be 24 hours of blocks, and the 
limit of X blocks, the blocks of 3 days.

So we have 2 possible situations to consider:

- 51% attack:  the blocks older than 24 hours are protected against a history 
rewrite during at least 3 days, in that time developers could release an 
emergency release with another mining algorithm to stop the attack.

- Network split: if the network split is older than N blocks, we have 2 
permanent forks (or chains), but in 3 days (or more) the blockchain heights 
will differ in more than X blocks (the blocks of 3 days) because there will be 
more miners in one chain than in the other so finally the loser chain will be 
abandoned and everyone will follow the longest chain.

It could be even more conservative, like 48 hours for the moving checkpoint and 
a block limit of 7 days of blocks.

Regards,




From: Ethan Heilman 
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] ; Bitcoin Dev 

Cc: Alistair Mann 
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

Attack 1:
I partition (i.e. eclipse) a bunch of nodes from the network this partition 
contains no mining power . I then mine 145 blocks for this partition. I don't 
even need 51% of the mining power because I'm not competing with any other 
miners. Under this rule this partition will hardfork from the network 
permanently. Under current rules this partition will be able to rejoin the 
network as the least weight chain will be orphaned.

Attack 2:
I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I feed 
it 145 blocks which fork off from the consensus chain. I have 24+24 hours to 
mine these 145 blocks so I should be able to do this with 25% of the current 
hash rate at the time the node went offline. Under your rule each of these 
offline-->online nodes I attack this way will hardfork themselves from the rest 
of the network.

I believe a moving-checkpoint rule as describe above would make Bitcoin more 
vulnerable to 51% attacks.

A safer rule would be if a node detects a fork with both sides of the split 
having  length > 144 blocks, it halts and requests user intervention to 
determine which chain to follow.  I don't think 144 blocks is a great number to 
use here as 24 hours is very short. I suspect you could improve the security of 
the rule by making the number of blocks a fork most reach to halt the network 
proportional to the difference in time between the timestamp in the block prior 
to the fork and the current time. I am **NOT** proposing Bitcoin adopt such a 
rule.

NXT has a fundamentally different security model as it uses Proof-of-stake 
rather than Proof-of-Work.

On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:
P.S.: To be clearer, in this example I set an N value of 144 blocks, which is 
approximately 24 hours.


From: Kenshiro [] mailto:tens...@hotmail.com>>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann mailto:a...@pectw.net>>; Bitcoin Protocol 
Discussion 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

>>> How would a (potentially, state-sponsored) netsplit lasting longer than N be
handled?

It would be detected by the community much before reaching the reorg limit of N 
blocks (it's 24 hours) so nodes could stop until the netsplit is fixed.

In the extreme case no one notice the network split during more than N blocks 
(24 hours) and there are 2 permanent forks longer than N, nodes from one branch 
could delete their local history so they would join the other branch.

Regards,



From: Alistair Mann mailto:a...@pectw.net>>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] mailto:tens...@hotmail.com>>; Bitcoin 
Protocol Discussion 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev 

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

[Adam Gibson via bitcoin-dev]

reposted due to wrong email address:

I'd just like to repeat something I said years ago but is undoubtedly lost
now:

>
> ### 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.
>

I criticised this point from the Moser paper at the time, in particular
because it was the headline grabbing result and in my opinion was only half
the truth, at best:

The $32K figure came from the assumption that swamping the bottom of the
order book (in other words, making lots of bots offering prices lower than
all the other bots) would lead to taking most of the join volume.

At the time, this was true and false to some extent: it was true that the
default order choosing algorithm was exponentially weighted to lower fees.
But it was also true even then that Takers could simply manually choose any
counterparty bots they liked (-P).

Also at the time I complained that it was trivial to implement other order
choosing algorithms, in particular I advocated (for its simplicity) "choose
randomly under a user specified maximum fee", and indeed since the paper we
have implemented that algorithm and it's now the default.

Note that this algorithm is the crudest variant of what was loosely called
"quantization" in this discussion between belcher and gmaxwell on the topic
some years ago:

https://github.com/JoinMarket-Org/joinmarket/issues/14#issuecomment-143509788

To me the crucial point is that the Taker's price sensitivity should not be
too large, although of course it cannot be zero!

So independent of changes in the makeup of the users of Joinmarket, that
analysis from 2016 was in my opinion a bit skewed at the time, and
completely wrong today.

None of this is a critique of the fidelity bonds idea, since the Sybil
threat is real in any case (see issue 693 as mentioned), but price-based
Sybilling is less effective than it seems based on that.

I'll continue my thoughts on fidelity bonds, for what they're worth, in the
active thread:
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/371

(for those not in the know, Joinmarket-Org/joinmarket-clientserver is the
active repo, not Joinmarket-Org/joinmarket).

Adam Gibson / waxwing / AdamISZ

On Thu, Jul 25, 2019 at 3:18 PM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> 

Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol

[Ethan Heilman via bitcoin-dev]

Attack 1:
I partition (i.e. eclipse) a bunch of nodes from the network this partition
contains no mining power . I then mine 145 blocks for this partition. I
don't even need 51% of the mining power because I'm not competing with any
other miners. Under this rule this partition will hardfork from the network
permanently. Under current rules this partition will be able to rejoin the
network as the least weight chain will be orphaned.

Attack 2:
I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I
feed it 145 blocks which fork off from the consensus chain. I have 24+24
hours to mine these 145 blocks so I should be able to do this with 25% of
the current hash rate at the time the node went offline. Under your rule
each of these offline-->online nodes I attack this way will hardfork
themselves from the rest of the network.

I believe a moving-checkpoint rule as describe above would make Bitcoin
more vulnerable to 51% attacks.

A safer rule would be if a node detects a fork with both sides of the split
having  length > 144 blocks, it halts and requests user intervention to
determine which chain to follow.  I don't think 144 blocks is a great
number to use here as 24 hours is very short. I suspect you could improve
the security of the rule by making the number of blocks a fork most reach
to halt the network proportional to the difference in time between the
timestamp in the block prior to the fork and the current time. I am **NOT**
proposing Bitcoin adopt such a rule.

NXT has a fundamentally different security model as it uses Proof-of-stake
rather than Proof-of-Work.

On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> P.S.: To be clearer, in this example I set an N value of 144 blocks, which
> is approximately 24 hours.
>
> --
> *From:* Kenshiro [] 
> *Sent:* Wednesday, July 31, 2019 16:40
> *To:* Alistair Mann ; Bitcoin Protocol Discussion <
> bitcoin-dev@lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> protocol
>
> >>> How would a (potentially, state-sponsored) netsplit lasting longer
> than N be
> handled?
>
> It would be detected by the community much before reaching the reorg limit
> of N blocks (it's 24 hours) so nodes could stop until the netsplit is
> fixed.
>
> In the extreme case no one notice the network split during more than N
> blocks (24 hours) and there are 2 permanent forks longer than N, nodes
> from one branch could delete their local history so they would join the
> other branch.
>
> Regards,
>
>
> --
> *From:* Alistair Mann 
> *Sent:* Wednesday, July 31, 2019 15:59
> *To:* Kenshiro [] ; Bitcoin Protocol Discussion <
> bitcoin-dev@lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> protocol
>
> On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:
>
> > I would like to propose that a "moving checkpoint" is added to the
> Bitcoin
> > protocol. It's a very simple rule already implemented in NXT coin:
> >
> > - A node will ignore any new block under nodeBlockHeight - N, so the
> > blockchain becomes truly immutable after N blocks, even during a 51%
> attack
> > which thanks to the moving checkpoint can't rewrite history older than
> the
> > last N blocks.
>
> How would a (potentially, state-sponsored) netsplit lasting longer than N
> be
> handled?
> --
> Alistair Mann
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Meta] bitcoin-dev moderation

[Bryan Bishop via bitcoin-dev]

On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev
 wrote:
> The current situation is that the moderation is slow and takes around
> >24h for a E-Mail to be on the mailing list

It really shouldn't be 24 hours. Our strategy was to have a few
moderators in different timezones to cover sleep shifts or other
disruptions of service. Evidently this has not been adequate.

> Jonas Schnelli proposed: "I propose that we add more moderators to
> shorten the moderation lag which has been between >24h, thus makes
> debates cumbersome"

Makes sense. I'll go find a few people.

> Beside this I had the idea of people who already contributed n e-mails
> to the mailing list don't need an approval for any e-mail anymore (Where
> n is the number of previous e-mails). Does this exists already?

There is an active software vulnerability which requires moderation to
be enabled. This version of mailman is unmaintained, and Linux
Foundation is migrating away from or abandoning the email protocol so
they are less willing to do backend infrastructure work. This
manifests in other ways, like downtime, but also weird situations like
missing emails that never hit the moderation queue. I get pings from
different people about two times a year where they report an email
that they think I missed, but in fact it never hit the moderation
queue at all. Email clearly isn't the greatest protocol.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future Extensibility

[Dmitry Petukhov via bitcoin-dev]

В Thu, 01 Aug 2019 19:01:06 +
Andrew Chow  wrote:

> I spoke to some people OOB and they said that they didn't really like
> the idea of having a prefix string (partially because they've already
> implemented some proprietary types by simply squatting on unused
> types). Matching the prefix string adds additional complexity to the
> parser code.

I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I
would like to note that for those who do not want to deal with
additional complexity of handling a prefixed string, they can simply
not use it at all. Since this is a private construction, and their
private format specifies 'no prefix', they can just ignore everything
that does not start with "{0xFC}|{0x00}", thus any further complexity
regarding the prefix is also ignored. The only added complexity is one
condition check: second_byte_of_the_key != 0 

My other argument for conflict-avoidance prefix as a first thing after
0xFC is that the set of future users of PSBT and private types is
most likely much larger than the current set of those who already
implemented proprietary types on their own, and thus the overall benefit
for the whole industry will likely be bigger when 'i do not want
conflict avoidance' decision have to be explicit, by setting the prefix
to 0x00, and the set of possible conflicting types are limited only to
those entities that made this explicit decision.

Regarding the 'squatted' types, it seems to me that this only matters
in the discussed context if they squatted on 0xFC type in particular.
In other cases, they will need to implement changes anyway, to be
compatible with the BIP. Maybe they could consider that one additional
condition check is a small burden, and maybe they can tolerate that,
for the benefit of reducing possibility of interoperability problems
between other future PSBT/private types implementors.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Chris Belcher via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev