From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 20 Feb 2024 16:12:01 -0800 Received: from mail-qt1-f184.google.com ([209.85.160.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rcaDR-0006yC-9j for bitcoindev@gnusha.org; Tue, 20 Feb 2024 16:12:01 -0800 Received: by mail-qt1-f184.google.com with SMTP id d75a77b69052e-42c7ce60175sf76166541cf.1 for ; Tue, 20 Feb 2024 16:12:00 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708474315; cv=pass; d=google.com; s=arc-20160816; b=Y4dKJ8/OBhKe7puJ9n7a/JFz2oTjHUGyPGg9H/mo9QivZHcB4EIa2kdrFUI6Fwx4oF J30CJaAwXFwAkCJhRSmhb2Fko/maIuGNeBcU1NsTZIhnghMmOG75zMwMsxin5JIFbHnX 5nTt0BTfcxQ9gahScnmnIMdU6+Lcs0NouAbSUEAAA6ZzXdXIfjKQxsWHuSLxtX/5+D2U hjVEqLHunEuftkw9Egd0GCzJaDdSF3lJG6/L2DMd+6/7Ch/JBUG5lUIiafKkULxNWwN6 OmHzsTzSpHl4ZtJnx0gw8YogmxKeuOI4VruH4ueGb7qi0YvKnoLtPHBqfcPlAtaYFWwK gDJA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=ml4AIYB0aJhYOTsCxZV10VOwlVvMblcvqriuV5PmDiY=; fh=M1s/BZnodVKBQtczafiKKOWiTZ7pnX4npV7SI5kWAA4=; b=o4peMuPySmMnapI+dThznAZUzNMwGvHRq5NBnYnyWJof5WwGUevGJPly9g5friHoWU QhKTa9BaKFXgHxe4aqKmWbSsatwzxuPWaZVaN7YhhF+GfTrowyWRMBSJMTo2DdDgVqKz 08H28W1ryFerdModaQHNml3qt8KV7PM4OzG6Cos3KnOq48l0WiMwMphRZFtqYA1lvmAB QAQCycf11qsG5ISFx/wu6rlVZItqydqYjML16fhpdWwTjIcWjffi2Qj/JEHU8JrCCzzR wURpJFPxcTA5MoEPtJB0ju8q4AKQidXyXsAGwtDAaT1tvZEbrpXCYLOfFGE2nyW/qpfH 9YvQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JnSVgcdL; spf=pass (google.com: domain of jlspc@protonmail.com designates 185.70.40.141 as permitted sender) smtp.mailfrom=jlspc@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1708474315; x=1709079115; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=ml4AIYB0aJhYOTsCxZV10VOwlVvMblcvqriuV5PmDiY=; b=W8NIFvG8a7/d+lFeF4WrbzmbAd2lf8NZdiLERiNLq09cByW7IyCu+PRaoJBLcfIF2+ 56rP3G3Mu3m71cqhndEBKCiCoJR8tkhb1Hsvxxx+qFlClMgbEiApBLu70kqgTxPo1YqE iypmbwNt5Xiscp2gT2iyDLRT7EABPKaQA9kxjDWO3Qdi4CATRX84FtHMD+c2m8p5qrBq 3f4PGIkhpPs1beTtM9h4x6WXgLw7bEva2WS5x8H4pc7FiPiKHUHNXYD6DgdiVw2Zf14O bmK473iRqPBqEBSVrCi8szit+4M7QFS0H5L62HEZvOxlSzZMzEbMVYVk4BdA0yeH6lr5 JUNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708474315; x=1709079115; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ml4AIYB0aJhYOTsCxZV10VOwlVvMblcvqriuV5PmDiY=; b=GskolUGICvUptlN9lCLi0YRCjxVTKD3d8f/HMfMlokL8hC+gN7v9mCNtCg3xPmlQI1 xZ0K+C5onU1B9XpRdQTuXAtE32+x/XvDWuPsJ4sUGPEDeSMuKQmlKDsF8utxBGUMtRL+ xdrdAkLhArvds5d0yOJwNkMToQDkT0N8UyTrxNRTyHSdbva/lqlpgGoa/AJd3p+PhfaT zSwGolI0LZGGuCGyjE7m1FNrO0aSimReWwOVLSeIo30LqR0Cz2ZDP0zco246DfmCAHO/ QK0rA6WTVi9NRxyh3i1QAug6U+Dy9t0yiCitWaqb/e/dHq7+izkFD/utrAAyAsQkjgFQ hPwA== X-Forwarded-Encrypted: i=2; AJvYcCU4srFCjWHb5svd3H3ftrj/+Qt5rnAalhfio3RygY94PVIiPaX8DPhj0o55DuzjfeUIY3nUwr5TM99NTS9UQEwM1w2eOAY= X-Gm-Message-State: AOJu0YzeJoc29zDStVBXMIFS6Q7vLNrSO3U20Qs58EvOiPdergU4tXM9 YGJ5HVBD7+4ruOOBw9URnMBY48JfliqlAWjcKP+hWe7jB/MGMniL X-Google-Smtp-Source: AGHT+IHbh0ut2iJyPE7+eGCxtPmrb2QqNTZHf3LIz2WrMrv3LxVZsft9OAGF1ildsu0P9jPkn2c9xQ== X-Received: by 2002:ac8:6e82:0:b0:42d:d4b0:69c2 with SMTP id c2-20020ac86e82000000b0042dd4b069c2mr14239701qtv.6.1708474314862; Tue, 20 Feb 2024 16:11:54 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ac8:5bc5:0:b0:42e:2ad0:3c7 with SMTP id b5-20020ac85bc5000000b0042e2ad003c7ls1157496qtb.1.-pod-prod-01-us; Tue, 20 Feb 2024 16:11:54 -0800 (PST) X-Received: by 2002:a05:622a:4c6:b0:42d:f64c:1945 with SMTP id q6-20020a05622a04c600b0042df64c1945mr31409qtx.9.1708474313917; Tue, 20 Feb 2024 16:11:53 -0800 (PST) Received: by 2002:a05:620a:1a90:b0:787:7243:30c with SMTP id af79cd13be357-78783e085f6ms85a; Tue, 20 Feb 2024 15:13:48 -0800 (PST) X-Received: by 2002:ac2:5f4d:0:b0:511:951f:f83d with SMTP id 13-20020ac25f4d000000b00511951ff83dmr5553455lfz.25.1708470826263; Tue, 20 Feb 2024 15:13:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1708470826; cv=none; d=google.com; s=arc-20160816; b=QNai5HinJ9ne3gu2ou3gMj98+4qNk75meYN/t4JsUDnkchFKYOO1Jtfhx5eM+cAoAU dUtJXpj6r0pDUuryU/k1vbPM8lT3kO1Ag7BoE7zusz+QlqBbgDxHw6Ik3+zJIlahdU+m L5sNxRe8nw2dsrl9zXbEe4ayeenpY0twunRD6nf6JTp5cEOZpKtUEVaSbcAxnRxwHCn3 ooZvTXlKpnuSHxv5sE+nVV1uaq4nUluM945YQTsJ48klPStnluK/RlqEZ7k76zdGOcI3 +XPs8PMcFfO+VZ9MU+OEYWI+0IR5jW9jRs3dyiNQ7FjkBl7EzskGEAOuoEvynSsiKnw/ OQnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=0Y8QfUtd5nd9dlp8oJ9bJkxJCKE++l+kNKgzW0ExSyQ=; fh=gXNd45OZp2Dl5EMOD2M5kLh5kHuPJ5ma2GN4K4dM9YM=; b=oqalPrD27fdqQInMDSKmPg0GToLKKfmdP0KW6kwgiz7ERwNG0Zt0mQpsCuiXvNfzPr pysaVg+lbbn14v8yVA/Gx1deMT13upBQ1yZIQEcWPw3HKlCHI+67BL1UQwK9I18SUdIt LsoMZ9zv7NHES9ttHUi6qJbpmTS1N4eQW/cUdq2doQgzdxCBzzTi0j6Tn9RjzlRM5M25 0WB4GWeVkJPVuofZCDMVPa7YHD4TiGFaVo/pbMFbRvMzwgRmBHRbl//s/POD8zYReTgn Dc5RLBsHOMkn/sVCO0pUc0DunBWi4CyDHCHg6lEHqgwz0PUJ/ifKGhq7xcDdjqjSejiv mrng==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JnSVgcdL; spf=pass (google.com: domain of jlspc@protonmail.com designates 185.70.40.141 as permitted sender) smtp.mailfrom=jlspc@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch. [185.70.40.141]) by gmr-mx.google.com with ESMTPS id k21-20020ac24f15000000b00511a71805a8si436925lfr.8.2024.02.20.15.13.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Feb 2024 15:13:46 -0800 (PST) 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 From: "'jlspc' via Bitcoin Development Mailing List" Cc: "bitcoindev@googlegroups.com" Subject: [bitcoindev] Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Message-ID: In-Reply-To: References: Feedback-ID: 36436663:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: jlspc@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JnSVgcdL; spf=pass (google.com: domain of jlspc@protonmail.com designates 185.70.40.141 as permitted sender) smtp.mailfrom=jlspc@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: jlspc Reply-To: jlspc Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) 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 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.