Bitcoin Forum
March 30, 2020, 01:04:18 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Soft forks  (Read 99 times)
domob
Legendary
*
Offline Offline

Activity: 1109
Merit: 1107


View Profile WWW
November 22, 2019, 05:58:24 AM
Merited by Carlton Banks (2)
 #21

1. big miner/pool thinks of a forking change to consensus
2. miner/pool implements it as a softfork
3. miner/pool releases new Bitcoin client with softfork included
4. miner/pool accepts the supa-dupa new tx's over their website (or maybe bake that into the client)
5. miner/pool begins including transactions in it's blocks, because no other miners are
6. miner/pool can inflate success of the fork, by stuffing blocks with tx's that they made themselves
7. miner/pool hopes everyone will follow the fork, bouyed by the (faked) success

That is certainly an interesting thought.  But I think at least in the case of a soft fork like segwit or BIP16 (which adds new transaction types that are only "secure" with the new rules), step 5/6 is quite risky.  As long as others are not enforcing the fork yet, everyone runs the risk of losing money if they already use those tx.  Even if they are submitted privately to the pool who enforces the rules, an attacker could just try to orphan one of the pool's blocks to steal funds from the tx in there.  (And stuffing their own blocks with tx like that would be risky for the pool - they likely need to include a lot of money in those tx as well for it to look realistic, and then someone could steal the pool's money if they orphan a block.)

And especially if the pool tries to make it look like "everyone is using the new feature already" (step 6), it would look quite suspicious that a lot of people were risking a lot of money in a way that is not yet secure at all.  So I doubt a) real people would start using such a fork before it is agreed and enforced, and b) others would believe the pool that lots of users already are, even if they stuff their own blocks.

But of course it depends on the concrete circumstances in the end.  Like the nature of the soft fork, and also how well the pool in question can perform the social engineering.  My argument assumes people are critically thinking and aware of the technical details, which might not be true enough....

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
1585530258
Hero Member
*
Offline Offline

Posts: 1585530258

View Profile Personal Message (Offline)

Ignore
1585530258
Reply with quote  #2

1585530258
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1585530258
Hero Member
*
Offline Offline

Posts: 1585530258

View Profile Personal Message (Offline)

Ignore
1585530258
Reply with quote  #2

1585530258
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3010
Merit: 3392



View Profile
November 22, 2019, 11:12:34 AM
Merited by Foxpup (8), Carlton Banks (5)
 #22

A majority of hashpower can add softforks.  They don't even have to publish software that are compatible with them, but they could.

For all we know-- there are some of these active now, invisible to us. -- though probably not. Smiley

The way carlton described it up thread-- it's not obvious why it could even be a problem.  If it was just some new transaction feature and it was useful and not bothering anyone else... then it might well be not a problem.  But it can take other forms where it clearly is a problem.

This has been raised as a weakness in Bitcoin's history-- and some have looked to solve it.  Usually the context it discusses is softforks that block a particular user (e.g. Bad Guy Bob) or style of transactions (e.g. Lightning payments).   Sometimes people have been concerned with fluffyforks-- ones where the rule will be bypassed if a violating chain gets ahead.

But it appears to be fundamentally hard to solve because a miner imposing a soft-fork is indistinguishable from an unmodified miner operating behind a network filter that hides certain transactions/blocks from it.  You could make sure they weren't getting filtered if there was some consensus about their inputs ... yo dawg I hurd u like blockchains.

There is obviously the nuclear option: If a majority hashpower is disruptive enough the users of Bitcoin will take some extreme action like changing to a new POW ...  But not only would that path be dangerous and disruptive (making it a less potent threat), it's unlikely to work if the attack is only harming a few users ("so sad Wikileaks can't move their funds, but not my problem").

So the open questions are: Are their less extreme defences than the nuclear option, is there a way to amplify attacks so that any amount of attacking will trigger the political will to fight back, can malicious softforks be stopped?

There has been advancement in a number of these dimensions.

Detection:   now that the network is operating against the weight limit most of the time there is little reason to have valid transactions rejected (except for forward compatibility reasons)--- transactions really should be being accepted in a fee-rate sensible order, and if they're not thats clear and detectable. So if it started happening at any scale, we could probably see it.

Amplification:  Coinjoins and sendmanys  link together the spends of multiple users, you can't block one input in a transaction without blocking them all.  More researchy right now, but non-interactive aggregate signatures have the property of building transaction bundles that cannot be unlinked. Both result in disruption amplification and additional fee income loss for miners that censor.

Indistinguishably:  Taproot should make different kinds of transactions much more indistinguishable (and an older technology, the coinswap transform can have similar indistinguishability benefits without taproot), and if usage types can't be distinguished they can't be targeted.  Similarly, privacy improving practices (avoiding reuse, coinjoins, swaps, anti-network-monitoring, p2p encryption)  can get in the way of censoring based on who's transacting.

Anonymous mining:  The system's existing incentives discourage leaving out any economical transactions -- after all, you'll miss out on their fees. But external pressures might make you act in ways that aren't rational within the system.  Tech like compact blocks, satellite block transmission, and not bloating the hell out of the maximum block size preserves the at least the threat that a lot of mining could go dark.

Mining distribution/security:  These attacks assume a majority hashrate is colluding against user interests. That's easier if mining is more centrally controlled. Betterhash/stratum2 make some steps in the direction of improving that.  There is probably a lot more to do to further decentralize mining control-- and this area has probably the least progress and some of the most importance for this issue.

In any case,  -- I hope this is some food for thought.
domob
Legendary
*
Offline Offline

Activity: 1109
Merit: 1107


View Profile WWW
November 22, 2019, 11:32:10 AM
 #23

Thanks for the informative post, there's indeed a lot of food for thought in it!

I'm just wondering about this bit:

Indistinguishably:  Taproot should make different kinds of transactions much more indistinguishable (and an older technology, the coinswap transform can have similar indistinguishability benefits without taproot), and if usage types can't be distinguished they can't be targeted.  Similarly, privacy improving practices (avoiding reuse, coinjoins, swaps, anti-network-monitoring, p2p encryption)  can get in the way of censoring based on who's transacting.

As far as I understand it, taproot allows you to build contracts whose "cooperation clause" is indistinguishable from ordinary payments.  But if you need to use a different branch of the contract (e.g. because you want to invoke a timeout condition and your transaction partner is not cooperating), you have to reveal it.  Wouldn't that mean that miners can again censor certain usage types?  Because even if they cannot censor the normal operation of some system like Lightning, I need to be sure that I can also get my transactions confirmed even if others on the contract do not cooperate.  (For instance, to close a channel if the other party is misbehaving.)  So if miners are censoring those transactions that invoke non-cooperative branches of a constract, then that effectively also censors the entire usecase.

Or am I misunderstanding how taproot works?

(I'm not saying this makes miner censorship a practical problem, since all the other reasons you cite are very valid.)

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 3010
Merit: 3392



View Profile
November 22, 2019, 12:50:29 PM
Last edit: November 22, 2019, 03:07:19 PM by gmaxwell
 #24

As far as I understand it, taproot allows you to build contracts whose "cooperation clause" is indistinguishable from ordinary payments.  But if you need to use a different branch of the contract (e.g. because you want to invoke a timeout condition and your transaction partner is not cooperating), you have to reveal it.

I didn't mean to give the impression that anything I mentioned is a fix-- they're all just incremental steps. The way I look at it, attacks are a question of incentives so even if we can just increase the cost a little or the effectiveness a little, or even just the uncertainty of the effectiveness, we're making it less likely that an attack is even attempted.

w/ Taproot you reveal only the clause you are executing, but not any of the other independent clauses.  So, for example, if your use case is only distinguishable by the sum total of the options from other activity-- then taproot hides it.  For example: if your spending possibilities might be "Cooperation" or "fallback A" or "fallback B"  and each of these options occurs separately as options in other kinds of transaction that miners wouldn't want to block, then yours can't be distinguished because all the miners see is the one option you used.

Just the fact that cooperation is indistinguishable from a boring spend is valuable on its own however--- for example,  the fact that miners could collude to make a particular fallback branch unreliable but users could still cooperate means that they couldn't e.g. straightforwardly freeze all funds that had been setup for use with that particular contract--  only those funds that were AND where cooperation wasn't possible.

I probably should have also mentioned P2SH as a big advance in this area (since it prevents block outputs with a specific script structure),  also scriptless scripts as useful ongoing research work along these same lines.
domob
Legendary
*
Offline Offline

Activity: 1109
Merit: 1107


View Profile WWW
November 22, 2019, 02:11:12 PM
 #25

w/ Taproot you reveal only the clause you are executing, but not any of the other independent clauses.  So, for example, if your use case is only distinguishable by the sum total of the options from other activity-- then taproot hides it.  For example: if your spending possibilities might be "Cooperation" or "fallback A" or "fallback B"  and each of these options occurs separately as options in other kinds of transaction that miners wouldn't want to block, then yours can't be distinguished because all the miners see is the one option you used.

Just the fact that cooperation is indistinguishable from a boring spend is valuable on its own however--- for example,  the fact that miners could collude to make a particular fallback branch unreliable but users could still cooperate means that they couldn't e.g. straightforwardly freeze all funds that had been setup for use with that particular contract--  only those funds that were AND where cooperation wasn't possible.

Very good points indeed, thanks for highlighting this!

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!