diff options
| author | Melvin Carvalho <melvincarvalho@gmail.com> | 2023-11-03 11:39:23 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-11-03 10:39:42 +0000 |
| commit | e17a9d95f458fb37b757caf3b4bf1a8e7fbd436e (patch) | |
| tree | 0aaa51825cebf8023ca93690a59097f92d13b058 | |
| parent | 2e0aa8b41f10b01b92ebd753b8fadfa39f5eefb8 (diff) | |
| download | pi-bitcoindev-e17a9d95f458fb37b757caf3b4bf1a8e7fbd436e.tar.gz pi-bitcoindev-e17a9d95f458fb37b757caf3b4bf1a8e7fbd436e.zip | |
Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
| -rw-r--r-- | 38/73436607dd9eaff8206175dd39d3ff6303a9ce | 454 |
1 files changed, 454 insertions, 0 deletions
diff --git a/38/73436607dd9eaff8206175dd39d3ff6303a9ce b/38/73436607dd9eaff8206175dd39d3ff6303a9ce new file mode 100644 index 000000000..31c62e708 --- /dev/null +++ b/38/73436607dd9eaff8206175dd39d3ff6303a9ce @@ -0,0 +1,454 @@ +Return-Path: <melvincarvalho@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 2ED8EC0032 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 3 Nov 2023 10:39:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id EB9E54F3E0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 3 Nov 2023 10:39:41 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org EB9E54F3E0 +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20230601 header.b=ge0kXDDf +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.099 +X-Spam-Level: +X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=1.999, + RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] + autolearn=no autolearn_force=no +Received: from smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id W4Te1dR0j7Zl + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 3 Nov 2023 10:39:37 +0000 (UTC) +Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com + [IPv6:2607:f8b0:4864:20::b2b]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 206384F3A9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 3 Nov 2023 10:39:37 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 206384F3A9 +Received: by mail-yb1-xb2b.google.com with SMTP id + 3f1490d57ef6-da0359751dbso1685455276.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 03 Nov 2023 03:39:37 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=gmail.com; s=20230601; t=1699007976; x=1699612776; + darn=lists.linuxfoundation.org; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date:message-id:reply-to; + bh=B1Yt0Lba6XYCxfh+d9XjcuSuWtTyXo/1OijLQyN89Mc=; + b=ge0kXDDfA5UdhT82Nu707g5qxjsr1f6SPv0HFOaGYkJwzuwtOOmg1TujYHESkRE9L6 + ad+yxY5RZe7thlA2QOmdLkGL3BKl8Vw8W2etL/C+YW9MBE3t9lU1ASLE35OMhY+0gTPl + /A5hoSL/61d/3onbM9N2a9WzDW9NeDmRtSvm9sds6tzXvWeQmm4jGH6OgzzeJJmDixZn + Pw6Bpr9S3JWgzJiwCdNZQvr9BGLGMqLHCGqHWUni2UhyhRXrwkgtMhTaYaUdd/EkpQZ5 + J56I8c7U/h3xCMgD4JZBkWLjYOYVpjuXOccZmJQtQtc9z5IWqsdjWcCdFdeAjxaftR41 + sqXg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20230601; t=1699007976; x=1699612776; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id + :reply-to; + bh=B1Yt0Lba6XYCxfh+d9XjcuSuWtTyXo/1OijLQyN89Mc=; + b=NvaGWd+KYnuKSgErFco5p+/TXygnfM5zLLK9vQQwNp/ayostJ2NMhn9f84YrRhLFBd + DRHGDRNerb9q+b0Al5StRnfBaAYnDgMQBLdKYt5eX3Q/tRldmEfX8IinBkydgnb/CMKy + myB0GahgNVScrNQAbsLZtJ9WxQ4T16eSrG8yAwX8iBukzL1xSk90FNtErJDQ2gVQ8TG1 + 3PuNA79Xr11yJzEPu70LpOWEhXxKx3Ns9ZW2ff5aZUQv2a/bVL0dHm3J5LsnzzDPGdBY + 0ude8OToaTLm9iPGjre+/d33OaYpDZBb8hvmf/AsVrOgH0pnSh6XrnfaQ+Jhs6V9TmRo + xn2g== +X-Gm-Message-State: AOJu0YzLy1jnwrUheddXhUs1JciUEnoyIhALtT/dZM6UHKzGaS5S5Tzj + hlii7dkq5pOu18sAzwteXXe/YFv0IM3brQhkpgCFGS4p +X-Google-Smtp-Source: AGHT+IGcDQSKMLUu1aov9S2HTDVyiX+cPeUPvpbprU+TcwKod94tHXl7yhMBzvb6GTKvFfovR5y4invwTjh7a6ZyIOw= +X-Received: by 2002:a25:2385:0:b0:d9b:c9be:f3d9 with SMTP id + j127-20020a252385000000b00d9bc9bef3d9mr1721871ybj.29.1699007975840; Fri, 03 + Nov 2023 03:39:35 -0700 (PDT) +MIME-Version: 1.0 +References: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com> + <CAKaEYh+Ya_W9zVXKbHr4eZWE=4tfCXvtZjvWRSmTjQTwyiKWRg@mail.gmail.com> + <46e412585ce8143727c40c66edae83e0@sonic.net> +In-Reply-To: <46e412585ce8143727c40c66edae83e0@sonic.net> +From: Melvin Carvalho <melvincarvalho@gmail.com> +Date: Fri, 3 Nov 2023 11:39:23 +0100 +Message-ID: <CAKaEYhKhsd0FKmGhfSSQ+2-P6GKLk2rAFrBJrpNaza0PuWApeQ@mail.gmail.com> +To: Brad Morrison <bradmorrison@sonic.net> +Content-Type: multipart/alternative; boundary="000000000000dee52006093d1e89" +X-Mailman-Approved-At: Fri, 03 Nov 2023 10:45:37 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject + non-standard Taproot transactions from full nodes? +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 03 Nov 2023 10:39:42 -0000 + +--000000000000dee52006093d1e89 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +p=C3=A1 3. 11. 2023 v 11:16 odes=C3=ADlatel Brad Morrison <bradmorrison@son= +ic.net> +napsal: + +> Melvin/all, +> +> You make good points about high network fees being disruptive. +> +> What is more disruptive are spikes & valleys (instability) that last +> longer than the mempool cycle can handle. +> +> Right now, https://mempool.space/ indicates that there are about 105,000 +> unconfirmed transactions and that current memory usage is 795 mb of 300 m= +b. +> +> We could compare the bitcoin networks' ability to process transactions to +> the California Independent System Operator's (CAISO - +> https://www.caiso.com/Pages/default.aspx) task of ensuring the CA +> electrical grid stays supplied with the least expensive electricity +> available and does not get overloaded, nor has to export too much +> electrical power to other grids in times of surplus. +> +> A big part of doing that is noticing past trends and preparing for future +> growth, if that is the goal. +> +> Expanding the block size is the simplest way to expand network capacity +> and lower transactional costs. +> + +The block size is a sensitive topic, as it has been used as an attack +vector in the past. It is now a loaded topic baked into the mythology of +the project. Discourse on the topic benefit from a dispassionate analysis +of the technical trade-offs and what properties of the network they affect. + +There exists an attack on bitcoin where the lowest fee rises to make it +much harder to participate. You could imagine a well funded attack, +creating fees of, say, 10,000 sats/vbyte, for a period of time. + +While this could be viewed as positive from one lens (miners benefit), +there would at least be a vocal minority, legitimately arguing that this is +disruptive to the ordinary function of the network. + +It's worth recognizing that a bigger block size makes this kind of +disruptive attack more expensive. + +It's a tricky topic because of the history, and because some of the "spam" +may be seen by some as legitimate. + +I think in the long-term miners and users will treat the fee auction in new +ways, with the use of AI algorithms. Trillions are transmitted through the +bitcoin network. A fraction of that is captured. As the block subsidy +goes away over the next 2 decades, it might lead to a kind of "AI mexican +standoff" where the highest value transactions pay a bit more for priority +transfers. AI will likely change the game theory, and we'll find out how, +over the next 2 epochs. + +If that is the case, then block size can increase with hardware advances, +while maintaining much valued decentralized properties of the network. In +this regard we probably would benefit from things like stratumv2 and +utreexo being rolled out first. + + +> Thank you, +> +> Brad +> +> +> +> On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote: +> +> +> +> po 8. 5. 2023 v 13:55 odes=C3=ADlatel Ali Sherief via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> napsal: +> +>> Hi guys, +>> +>> I think everyone on this list knows what has happened to the Bitcoin +>> mempool during the past 96 hours. Due to side projects such as BRC-20 +>> having such a high volume, real bitcoin transactions are being priced ou= +t +>> and that is what is causing the massive congestion that has arguable not +>> been seen since December 2017. I do not count the March 2021 congestion +>> because that was only with 1-5sat/vbyte. +>> +>> Such justifiably worthless ("worthless" is not even my word - that's how +>> its creator described them[1]) tokens threaten the smooth and normal use= + of +>> the Bitcoin network as a peer-to-pear digital currency, as it was intend= +ed +>> to be used as. +>> +>> If the volume does not die down over the next few weeks, should we take +>> an action? The bitcoin network is a triumvirate of developers, miners, a= +nd +>> users. Considering that miners are largely the entities at fault for +>> allowing the system to be abused like this, the harmony of Bitcoin +>> transactions is being disrupted right now. Although this community has a +>> strong history of not putting its fingers into pies unless absolutely +>> necessary - an example being during the block size wars and Segwit - sho= +uld +>> similar action be taken now, in the form of i) BIPs and/or ii) commits i= +nto +>> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which +>> defines the validation rules for Taproot scripts) which has allowed thes= +e +>> unintended consequences? +>> +>> An alternative would be to enforce this "censorship" at the node level +>> and introduce a run-time option to instantly prune all non-standard Tapr= +oot +>> transactions. This will be easier to implement, but won't hit the road +>> until minimum next release. +>> +>> I know that some people will have their criticisms about this, +>> absolutists/libertarians/maximum-freedom advocates, which is fine, but w= +e +>> need to find a solution for this that fits everyone's common ground. We +>> indirectly allowed this to happen, which previously wasn't possible befo= +re. +>> So we also have a responsibility to do something to ensure that this kin= +d +>> of congestion can never happen again using Taproot. +>> +> +> This is a nuanced and sensitive topic that has been discussed previously, +> as far back as 2010, in a conversation between Gavin and Satoshi: +> +> https://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617 +> +> Gavin: That's a cool feature until it gets popular and somebody decides i= +t +> would be fun to flood the payment network with millions of transactions t= +o +> transfer the latest Lady Gaga video to all their friends... +> Satoshi: That's one of the reasons for transaction fees. There are other +> things we can do if necessary. +> +> High fees could be viewed as disruptive to the network, but less +> disruptive than regular large reorgs, or a network split. +> +> It might be beneficial to brainstorm the "other things we can do if +> necessary". +> +> A simple observation is that increasing the block size could make it more +> challenging to spam, though it may come at the expense of some +> decentralization. +> +> +>> +>> -Ali +>> +>> --- +>> +>> [1]: +>> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the= +-promise-and-peril-of-bitcoin-backed-tokens/ +>> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-th= +e-promise-and-peril-of-bitcoin-backed-tokens/?outputType=3Damp> +>> +>> _______________________________________________ +>> 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 +> +> + +--000000000000dee52006093d1e89 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= +<div dir=3D"ltr" class=3D"gmail_attr">p=C3=A1 3. 11. 2023 v=C2=A011:16 odes= +=C3=ADlatel Brad Morrison <<a href=3D"mailto:bradmorrison@sonic.net">bra= +dmorrison@sonic.net</a>> napsal:<br></div><blockquote class=3D"gmail_quo= +te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= +);padding-left:1ex"><div style=3D"font-size:10pt"> +<p>Melvin/all, </p> +<p>You make good points about high network fees being disruptive.</p> +<p>What is more disruptive are spikes & valleys (instability) that last= + longer than the mempool cycle can handle.</p> +<p>Right now, <a href=3D"https://mempool.space/" target=3D"_blank">https://= +mempool.space/</a> indicates that there are about 105,000 unconfirmed trans= +actions and that current memory usage is 795 mb of 300 mb.</p> +<p>We could compare the bitcoin networks' ability to process transactio= +ns to the California Independent System Operator's (CAISO - <a href=3D"= +https://www.caiso.com/Pages/default.aspx)" target=3D"_blank">https://www.ca= +iso.com/Pages/default.aspx)</a> task of ensuring the CA electrical grid sta= +ys supplied with the least expensive electricity available and does not get= + overloaded, nor has to export too much electrical power to other grids in = +times of surplus.</p> +<p>A big part of doing that is noticing past trends and preparing for futur= +e growth, if that is the goal.</p> +<p>Expanding the block size is the simplest way to expand network capacity = +and lower transactional costs.</p></div></blockquote><div><br></div><div>Th= +e block size is a sensitive topic, as it has been used as an attack vector = +in the past.=C2=A0 It is now a loaded topic baked into the mythology of the= + project.=C2=A0 Discourse on the topic benefit from a dispassionate analysi= +s of the technical trade-offs and what properties of the network they affec= +t.<br></div><div><br></div>There exists an attack on bitcoin where the lowe= +st fee rises to make it much harder to participate.=C2=A0 You could imagine= + a well funded attack, creating fees of, say, 10,000 sats/vbyte, for a peri= +od of time.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q= +uote">While this could be viewed as positive from one lens (miners benefit)= +, there would at least be a vocal minority, legitimately arguing that this = +is disruptive to the ordinary function of the network.</div><div class=3D"g= +mail_quote"><br></div><div class=3D"gmail_quote">It's worth recognizing= + that a bigger block size makes this kind of disruptive attack more expensi= +ve.<br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote= +">It's a tricky topic because of the history, and because some of the &= +quot;spam" may be seen by some as legitimate.</div><div class=3D"gmail= +_quote"><br></div><div class=3D"gmail_quote">I think in the long-term miner= +s and users will treat the fee auction in new ways, with the use of AI algo= +rithms.=C2=A0 Trillions are transmitted through the bitcoin network.=C2=A0 = +A fraction of that is captured.=C2=A0 As the block subsidy goes away over t= +he next 2 decades, it might lead to a kind of "AI mexican standoff&quo= +t; where the highest value transactions pay a bit more for priority transfe= +rs.=C2=A0 AI will likely change the game theory, and we'll find out how= +, over the next 2 epochs.=C2=A0 <br></div><div class=3D"gmail_quote"><br></= +div><div class=3D"gmail_quote">If that is the case, then block size can inc= +rease with hardware advances, while maintaining much valued decentralized p= +roperties of the network.=C2=A0 In this regard we probably would benefit fr= +om things like stratumv2 and utreexo being rolled out first.=C2=A0 <br></di= +v><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_qu= +ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= +4);padding-left:1ex"><div style=3D"font-size:10pt"> +<p>Thank you,</p> +<p>Brad</p> +<div>=C2=A0</div> +<p><br></p> +<p>On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote:</p> +<blockquote type=3D"cite" style=3D"padding:0px 0.4em;border-left:2px solid = +rgb(16,16,255);margin:0px"> +<div dir=3D"ltr"> +<div dir=3D"ltr">=C2=A0</div> +<br> +<div class=3D"gmail_quote"> +<div class=3D"gmail_attr" dir=3D"ltr">po 8. 5. 2023 v=C2=A013:55 odes=C3=AD= +latel Ali Sherief via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.l= +inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= +</a>> napsal:</div> +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left:1px solid rgb(204,204,204);padding-left:1ex"> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">Hi guys,</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">I think everyone= + on this list knows what has happened to the Bitcoin mempool during the pas= +t 96 hours. Due to side projects such as BRC-20 having such a high volume, = +real bitcoin transactions are being priced out and that is what is causing = +the massive congestion that has arguable not been seen since December 2017.= + I do not count the March 2021 congestion because that was only with 1-5sat= +/vbyte.</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">Such justifiably= + worthless ("worthless" is not even my word - that's how its = +creator described them[1]) tokens threaten the smooth and normal use of the= + Bitcoin network as a peer-to-pear digital currency, as it was intended to = +be used as.</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">If the volume do= +es not die down over the next few weeks, should we take an action? The bitc= +oin network is a triumvirate of developers, miners, and users. Considering = +that miners are largely the entities at fault for allowing the system to be= + abused like this, the harmony of Bitcoin transactions is being disrupted r= +ight now. Although this community has a strong history of not putting its f= +ingers into pies unless absolutely necessary - an example being during the = +block size wars and Segwit - should similar action be taken now, in the for= +m of i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail = +the loophole in BIP 342 (which defines the validation rules for Taproot scr= +ipts) which has allowed these unintended consequences?</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">An alternative w= +ould be to enforce this "censorship" at the node level and introd= +uce a run-time option to instantly prune all non-standard Taproot transacti= +ons. This will be easier to implement, but won't hit the road until min= +imum next release.</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">I know that some= + people will have their criticisms about this, absolutists/libertarians/max= +imum-freedom advocates, which is fine, but we need to find a solution for t= +his that fits everyone's common ground. We indirectly allowed this to h= +appen, which previously wasn't possible before. So we also have a respo= +nsibility to do something to ensure that this kind of congestion can never = +happen again using Taproot.</div> +</blockquote> +<div>=C2=A0</div> +</div> +<div class=3D"gmail_quote">This is a nuanced and sensitive topic that has b= +een discussed previously, as far back as 2010, in a conversation between Ga= +vin and Satoshi: </div> +<div class=3D"gmail_quote">=C2=A0</div> +<div class=3D"gmail_quote"><a href=3D"https://bitcointalk.org/index.php?top= +ic=3D195.msg1617#msg1617" rel=3D"noopener noreferrer" target=3D"_blank">htt= +ps://bitcointalk.org/index.php?topic=3D195.msg1617#msg1617</a></div> +<div class=3D"gmail_quote"><br>Gavin: That's a cool feature until it ge= +ts popular and somebody decides it would be fun to flood the payment networ= +k with millions of transactions to transfer the latest Lady Gaga video to a= +ll their friends...<br>Satoshi: That's one of the reasons for transacti= +on fees.=C2=A0 There are other things we can do if necessary. +<div>=C2=A0</div> +<div class=3D"gmail_quote">High fees could be viewed as disruptive to the n= +etwork, but less disruptive than regular large reorgs, or a network split.<= +/div> +<div class=3D"gmail_quote">=C2=A0</div> +</div> +<div class=3D"gmail_quote">It might be beneficial to brainstorm the "o= +ther things we can do if necessary".</div> +<div class=3D"gmail_quote">=C2=A0</div> +<div>A simple observation is that increasing the block size could make it m= +ore challenging to spam, though it may come at the expense of some decentra= +lization.</div> +<div>=C2=A0</div> +<div class=3D"gmail_quote"> +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left:1px solid rgb(204,204,204);padding-left:1ex"> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">-Ali</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">---</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">[1]:=C2=A0<span>= +<a href=3D"https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-= +brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=3Damp" rel= +=3D"noopener noreferrer" target=3D"_blank">https://www.coindesk.com/consens= +us-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backe= +d-tokens/</a></span></div> +<div style=3D"font-family:Arial,sans-serif;font-size:14px">=C2=A0</div> +_______________________________________________<br> bitcoin-dev mailing lis= +t<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b= +lank">bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://list= +s.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noopener norefer= +rer" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/b= +itcoin-dev</a></blockquote> +</div> +</div> +<br> +<div style=3D"margin:0px;padding:0px;font-family:monospace">_______________= +________________________________<br> bitcoin-dev mailing list<br> <a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= +-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfounda= +tion.org/mailman/listinfo/bitcoin-dev" rel=3D"noopener noreferrer" target= +=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= +/a></div> +</blockquote> +</div> +</blockquote></div></div> + +--000000000000dee52006093d1e89-- + |