diff options
| author | alicexbt <alicexbt@protonmail.com> | 2023-02-19 00:33:11 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-02-19 00:33:27 +0000 |
| commit | 5df993bbcddc081faacc54470c758c1616ae0d81 (patch) | |
| tree | 439278b192cea2342792cc8136a94b50a89eaf3e | |
| parent | 825c24d1edfb0499edbc34eac789ca1464eb0b51 (diff) | |
| download | pi-bitcoindev-5df993bbcddc081faacc54470c758c1616ae0d81.tar.gz pi-bitcoindev-5df993bbcddc081faacc54470c758c1616ae0d81.zip | |
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
| -rw-r--r-- | 9e/e3da416b5076de1afcde898dbb8d4eff0a1bf6 | 258 |
1 files changed, 258 insertions, 0 deletions
diff --git a/9e/e3da416b5076de1afcde898dbb8d4eff0a1bf6 b/9e/e3da416b5076de1afcde898dbb8d4eff0a1bf6 new file mode 100644 index 000000000..0e28b9cfd --- /dev/null +++ b/9e/e3da416b5076de1afcde898dbb8d4eff0a1bf6 @@ -0,0 +1,258 @@ +Return-Path: <alicexbt@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 7BFDAC002B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Feb 2023 00:33:27 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 44FEE40588 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Feb 2023 00:33:27 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 44FEE40588 +Authentication-Results: smtp2.osuosl.org; + dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com + header.a=rsa-sha256 header.s=protonmail3 header.b=hBgP9Xu3 +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.101 +X-Spam-Level: +X-Spam-Status: No, score=-2.101 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, + SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id e-r9fSyXHzpp + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Feb 2023 00:33:25 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6FA2940122 +Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 6FA2940122 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 19 Feb 2023 00:33:24 +0000 (UTC) +Date: Sun, 19 Feb 2023 00:33:11 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1676766801; x=1677026001; + bh=AjtxeZyNxgTXMrqhlxT9jU4hJaF4Pp50dlKskmKxUOo=; + h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: + Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: + Message-ID:BIMI-Selector; + b=hBgP9Xu3u/wxmFGcWyQLTvsbqQ1K0HRDceO/WrZ7ULD7W96PoUfFYzR03j6SKvHbR + FEZpyCM8Aa/5dfDr9MpI0rVuufCwUmpnvyswWZtM6szvpvC4OHfVa5p76zL0YVSm3x + zhO1WO44GSpARkODtoEYaXvo6165Qf5XVUVrYvg2wHeYrxLrDDFmYPcmHp5RmvWg8A + pa8wSUGn6DZlAIDbVtj4aOi+bQ2vl8lV1eajfN7UkIDERrmxc6CLL5saNlp18I11eH + JvnLdPx/NmQMM5UJ2HRrlJi7bHjBjSmVZHP1d9Xo5FNkUVx7hgJf7t/iGkgstPTkvz + dyvzHb+o1QWKQ== +To: vjudeu@gazeta.pl +From: alicexbt <alicexbt@protonmail.com> +Message-ID: <T-fJqnql1ZDCPF95PkotBhXswPgfI84UZYUwin4pNTFbWFn5iXPoWX8uvVk8-Mok0VuUqtLONhNqQy5TRSOwwaxaLz_rpReFO9W2Hl6osE0=@protonmail.com> +In-Reply-To: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet> +References: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet> +Feedback-ID: 40602938:user:proton +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +X-Mailman-Approved-At: Sun, 19 Feb 2023 12:48:08 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p + network +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: Sun, 19 Feb 2023 00:33:27 -0000 + +Hi vjudeu, + +Before I respond to your email, I would like to share the [python script][0= +] that could be used to do 3 things: + +1) List peers +2) Broadcast a transaction to peers and see if it was relayed +3) Ban peers that did not relay your transaction + +The primary goal of this script is testing however it can be used by anyone= + as it does not make sense to waste resources connecting to peers that do n= +ot relay your transactions. There is another [solution][1] for users to ens= +ure all transactions get relayed properly. + +Note: There could be some false positives and it mainly uses libbtc + +> Yes, I disapprove spamming the blockchain. But because people will rather= + die than stop it, creating some kind of official alternative is needed. I = +think most of the time it is not needed to store that data on-chain, all th= +at is needed, is just proving they existed, and that they are connected to = +a certain transaction (so, it is about timestamping, not about storage). + +Why do you think people don't stop and willing to pay for inscribing someth= +ing on-chain although it could be done for free using BitTorrent? As far as= + 'spam' is concerned these are bitcoin transactions until you open ordinals= + explorer or believe in ordinals theory to track the ownership of inscripti= +on. There are some bitcoin transactions that I could consider spam and have= + no interest in keeping them on my disk. However I believe people should be= + free to do anything with their money and I don't care about the content or= + intent of any bitcoin transaction as long as its valid, paid fee etc. (exc= +ept vulnerability) Blocks cannot exceed their limit and I was prepared for = +a fee market with new limits since segwit got activated. + +Here's my opinion why people don't stop doing it and we could always disagr= +ee: + +Money or financial transactions have been done differently in countries, cu= +ltures, communities etc. across the world. People have done inscriptions on= + paper money issued by governments for graffiti, political, personal or oth= +er reasons. Since years inscriptions have been on different types of [coins= +][2]. Example: Jahangir issued many gold and silver [coins with poetic vers= +es][3] on them and was the only Mughal emperor to bestow the right of coina= +ge to his royal consort. + +Some positives of inscriptions that I have observed in last couple of weeks= +: + +- More users interested in running full nodes (non-pruned) and trying bitco= +in wallets, lightning etc. +- Taproot usage increased +- More developers interested in learning bitcoin development and looking fo= +r libraries, docs etc. +- Demand for block space has increased +- ~50 BTC paid in fees to miners for creating inscriptions until now + +It creates more opportunities for bitcoin developers and everyone involved = +in bitcoin. + +[0]: https://ordinals.com/content/f39b5f0a9e9af05da03ab0c52a407972b9678e8db= +80160febd6bd899acebe141i0 +[1]: https://github.com/casey/ord/pull/1783 +[2]: https://en.wikipedia.org/wiki/Coinage_of_India +[3]: https://web.archive.org/web/20180705070913/https://www.mintageworld.co= +m/blog/coins-of-jahangir/ + + +/dev/fd0 +floppy disk guy + +Sent with Proton Mail secure email. + +------- Original Message ------- +On Friday, February 17th, 2023 at 8:26 PM, vjudeu via bitcoin-dev <bitcoin-= +dev@lists.linuxfoundation.org> wrote: + + +>=20 +> I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NO= +PS. Because "OP_FALSE OP_IF <anything> OP_ENDIF" is effectively the same as= + "OP_NOP", and putting NOPs in many places is considered non-standard. The = +same is true for "OP_TRUE OP_NOTIF <anything> OP_ENDIF", and also there are= + many variants, where someone could use "OP_FALSE OP_NOT" instead of "OP_TR= +UE", or check if "2+2=3D=3D4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" (in= +stead of putting "OP_TRUE"). +>=20 +>=20 +> There are endless combinations, and even if there will be a rule to evalu= +ate constant values on the input stack, and put OP_NOP, where any non-empty= + set of opcodes will evaluate into nothing, then still, there are ways to i= +nclude spam on-chain. So, the question is: how strict should those rules be= +? +>=20 +> > "I disapprove of what you say, but I will defend to the death your righ= +t to say it." +>=20 +>=20 +> Yes, I disapprove spamming the blockchain. But because people will rather= + die than stop it, creating some kind of official alternative is needed. I = +think most of the time it is not needed to store that data on-chain, all th= +at is needed, is just proving they existed, and that they are connected to = +a certain transaction (so, it is about timestamping, not about storage). +>=20 +> When it comes to the solution, I think a commitment to a signature should= + handle all cases. In this way, it can be done for any address type that ca= +n support OP_CHECKSIG. To validate such commitment, all that is needed, is = +converting R-value of a signature into the Taproot address, and then checki= +ng if a given commitment matches such key. +>=20 +> > I agree with Peter that, given that users have found ways to store arbi= +trary amounts of data on-chain if they really want, we might as well just m= +ake OP_RETURN a free-for-all. +>=20 +>=20 +> I think we should go in the opposite direction. Using OP_RETURN means tha= +t all nodes will store such data. Using witness means that only witness nod= +es will keep that. So, if it is already possible to have a node that cannot= + see witness data, and still remain in the network, I think commitments sho= +uld be stored only by nodes that will enable them explicitly. So, from that= + point of view, commitment is "a witness of a signature", it is additional = +information that can be skipped if needed. +>=20 +> On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev bitcoin-dev@lists.li= +nuxfoundation.org wrote: +>=20 +> > Hi Bitcoin Developers, +>=20 +>=20 +> There is a famous quote attributed to Evelyn Beatrice Hall in her biograp= +hy of Voltaire: "I disapprove of what you say, but I will defend to the dea= +th your right to say it." I'm curious to know how many Bitcoin developers s= +hare this sentiment. +>=20 +> Recently there was a lot of enthusiasm on social media to run bitcoin cor= +e with a patch that would reject some transactions in mempool. Bitcoin Knot= +s already has an option to reject transactions that reuse addresses. What i= +f such practices become common and some projects that provide easy to use n= +ode software start censoring transactions? How would government agencies ta= +ke advantage of this whole drama? +>=20 +> I understand it is difficult to censor different type of transaction beca= +use there will be some nodes relaying them and miners including in blocks. = +It is still important to discuss this and different ways to test censorship= + resistance. +>=20 +> - Peter Todd had written a [blog post][1] in which counting number of INV= +s (step 5,6,7 and 8) helps in testing if your transactions are getting rela= +yed by the connected peers. +> - I had tried broadcasting transaction to specific nodes using [libbtc][2= +]. Based on my understanding it uses GETDATA to confirm your transaction wa= +s seen on other nodes after broadcasting. +>=20 +> What would an ideal tool for testing censorship resistance look like? +>=20 +> - Allows user to construct different types of transactions that might be = +considered "bad" by some people. Example: OFAC address in output, Inscripti= +on, OP_RETURN, Address reuse etc. +> - Option to broadcast transaction to specific nodes +> - Verify if the transaction was relayed successfully or rejected +> - Ban such peers using [setban][3] RPC as it would increase the probabili= +ty of tx getting propagated to miners +>=20 +> There was even some discussion about an [external mempool][4] that could = +be used for non-standard transactions. It could also help in avoiding censo= +rship in some cases. I welcome your thoughts and feedback on this topic. +>=20 +> 0: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 +> [1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf +> [2]: https://twitter.com/1440000bytes/status/1574225052240777216 +> [3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/ +> [4]: https://twitter.com/jamesob/status/1623827708168863747 +>=20 +> /dev/fd0 +> floppy disc guy +>=20 +> Sent with Proton Mail secure email. +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |