Delivery-date: Tue, 20 Feb 2024 16:12:01 -0800
Received-SPF: pass (google.com: domain of jlspc@protonmail.com designates 185.70.40.141 as permitted sender) client-ip=185.70.40.141;
Date: Tue, 20 Feb 2024 23:13:35 +0000
To: Peter Todd <pete@petertodd.org>
From: "'jlspc' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due
 to UTXO's Required For Fee Payment
Message-ID: <PnCfwvddzyZz4IZayq9GxSFhmc77F9-eL0EnnAl3QMNNB-S_FppHP8QXZ4ZR-9LoBW_6B3_GC3FqfpykjFUHGrR-hmNQ4_XJSGBH0CriI9g=@protonmail.com>
In-Reply-To: <Zbh/9fKrnid/psA/@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org> <Gr0X5c-3nQcx-VLD3eQ-e0DoOFim5gUKeyOF5ViYPfjE030KB4QJ2tVyA4wfY64Um_zo0fTfjqkTN11-RcvDeiAVhE2_9VYcQ3kSGFD1dug=@protonmail.com> <Zbh/9fKrnid/psA/@petertodd.org>
Feedback-ID: 36436663:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Reply-To: jlspc <jlspc@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hi Peter,

Yes, Bitcoin's security should be based on all parties following economic i=
ncentives.
As you explain very convincingly in your V3 post [1], it's essential that m=
iners' economic incentives don't include receiving offchain payments for th=
eir mining decisions.
If we're successful in preventing incentives for offchain payments (e.g., b=
y avoiding the use of anchor outputs for paying fees [1]), then the onchain=
 fees will represent the true cost of putting transactions onchain.

Even without other incentives for offchain payments, if feerate-dependent t=
imelocks (FDTs) were used to secure Layer 2 protocols, miners could collude=
 with the operators of the Layer 2 protocols to mine blocks with artificial=
ly low median feerates and thus steal funds.
However, miners can already create reorgs that enable double-spends and ste=
al funds.
The defences against FDT attacks are similar to the defences against double=
-spend attacks.
In both cases, a conservative choice of security parameters (namely FDT par=
ameters or safe_confirmation_depth blocks) virtually eliminates the possibi=
lity of a successful attack involving less than 45% of the hashpower.
For example, an FDT with 16k window_size and 1k block_count has less than a=
 10^-33 chance of being artificially manipulated by miners with 45% of the =
hashpower.

Thus, in both cases, the key issue is whether or not a majority of hashpowe=
r (or at least more than 45% of it) will collude in order to enable theft.
In the case of double-spend attacks, if a majority of the hashpower collude=
d in order to steal funds from deep in the blockchain, the attack would be =
highly-visible and would likely backfire due to damage to the value of bitc=
oin and/or other responses.
Similarly, if FDTs were used to secure funds in Lightning channels, channel=
 factories, or Timeout-Trees, and if a majority of the hashpower colluded i=
n order to manipulate FDTs to steal those funds, the attack would again be =
highly-visible and likely to backfire.

It would be ideal if we could invent something that prevents forced expirat=
ion spam attacks without relying on detecting a spike in onchain fees.
Such an invention would be strictly better than FDTs.
However, I'm not aware of any such invention, and there's a case to be made=
 that FDTs (or something else that's defined in terms of onchain fees) are =
our best chance for preventing forced expiration spam attacks [2].

This observation only strengthens your argument that we should avoid anythi=
ng (such as the use of anchor outputs for paying fees) that rewards miners =
for receiving offchain payments [1].
Offchain fees endanger not only miner decentralization, but also our abilit=
y to scale Bitcoin without incentivizing forced expiration spam attacks.

Given that Bitcoin will be far more valuable if it is decentralized and if =
it can scale safely, all parties (including miners) should want to keep fee=
s onchain.

Regards,
John

[1] https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-=
danger-to-mining-decentralization
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/0=
22198.html


Sent with Proton Mail secure email.

On Monday, January 29th, 2024 at 8:49 PM, Peter Todd <pete@petertodd.org> w=
rote:

> On Thu, Jan 25, 2024 at 05:49:26PM +0000, jlspc wrote:
>
> > Hi Peter,
> >
> > If feerate-dependent timelocks (FDTs) (1) are supported, it would be po=
ssible to use CTV to define a transaction with a fixed fee and no anchor ou=
tputs, as long as it's racing against a transaction with an FDT.
>
>
> Fee-rate-dependant timelocks have obvious issues around manipulation of
> observed fee-rates by miners. It not unreasonable to say they assume mine=
rs are
> honest, which is a significant weakening of the economic incentive-based
> security model we usually assume in Bitcoin.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/PnCfwvddzyZz4IZayq9GxSFhmc77F9-eL0EnnAl3QMNNB-S_FppHP8QXZ4ZR-9Lo=
BW_6B3_GC3FqfpykjFUHGrR-hmNQ4_XJSGBH0CriI9g%3D%40protonmail.com.