From: "'jlspc' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Peter Todd <pete@petertodd•org>
Cc: "bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Date: Tue, 20 Feb 2024 23:13:35 +0000 [thread overview]
Message-ID: <PnCfwvddzyZz4IZayq9GxSFhmc77F9-eL0EnnAl3QMNNB-S_FppHP8QXZ4ZR-9LoBW_6B3_GC3FqfpykjFUHGrR-hmNQ4_XJSGBH0CriI9g=@protonmail.com> (raw)
In-Reply-To: <Zbh/9fKrnid/psA/@petertodd.org>
Hi Peter,
Yes, Bitcoin's security should be based on all parties following economic incentives.
As you explain very convincingly in your V3 post [1], it's essential that miners' economic incentives don't include receiving offchain payments for their mining decisions.
If we're successful in preventing incentives for offchain payments (e.g., by 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 timelocks (FDTs) were used to secure Layer 2 protocols, miners could collude with the operators of the Layer 2 protocols to mine blocks with artificially low median feerates and thus steal funds.
However, miners can already create reorgs that enable double-spends and steal 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 parameters or safe_confirmation_depth blocks) virtually eliminates the possibility 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 hashpower (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 colluded 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 bitcoin 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 in 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 expiration 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 anything (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 ability 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 fees 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/022198.html
Sent with Proton Mail secure email.
On Monday, January 29th, 2024 at 8:49 PM, Peter Todd <pete@petertodd•org> wrote:
> 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 possible to use CTV to define a transaction with a fixed fee and no anchor outputs, 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 miners 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
--
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 email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/PnCfwvddzyZz4IZayq9GxSFhmc77F9-eL0EnnAl3QMNNB-S_FppHP8QXZ4ZR-9LoBW_6B3_GC3FqfpykjFUHGrR-hmNQ4_XJSGBH0CriI9g%3D%40protonmail.com.
next prev parent reply other threads:[~2024-02-21 0:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 19:31 Peter Todd
2024-01-25 12:57 ` Michael Folkson
2024-01-30 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2024-01-30 4:38 ` Peter Todd
2024-01-30 5:07 ` ZmnSCPxj
2024-01-30 5:17 ` ZmnSCPxj
2024-01-30 5:55 ` Anthony Towns
2024-01-30 8:40 ` Peter Todd
2024-01-25 17:49 ` [bitcoin-dev] " jlspc
2024-01-30 4:49 ` Peter Todd
2024-02-20 23:13 ` 'jlspc' via Bitcoin Development Mailing List [this message]
2024-01-27 6:28 ` Brandon Black
2024-01-30 4:46 ` Peter Todd
[not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
2024-01-30 4:41 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='PnCfwvddzyZz4IZayq9GxSFhmc77F9-eL0EnnAl3QMNNB-S_FppHP8QXZ4ZR-9LoBW_6B3_GC3FqfpykjFUHGrR-hmNQ4_XJSGBH0CriI9g=@protonmail.com' \
--to=bitcoindev@googlegroups.com \
--cc=jlspc@protonmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox