path: root/9e/e3da416b5076de1afcde898dbb8d4eff0a1bf6

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