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 not relay your transactions. There is another [solution][1] for users to ensure 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 that 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 something 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 inscription. 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. (except 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 disagree: Money or financial transactions have been done differently in countries, cultures, communities etc. across the world. People have done inscriptions on paper money issued by governments for graffiti, political, personal or other reasons. Since years inscriptions have been on different types of [coins][2]. Example: Jahangir issued many gold and silver [coins with poetic verses][3] on them and was the only Mughal emperor to bestow the right of coinage 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 bitcoin wallets, lightning etc. - Taproot usage increased - More developers interested in learning bitcoin development and looking for 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/f39b5f0a9e9af05da03ab0c52a407972b9678e8db80160febd6bd899acebe141i0 [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.com/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: > > I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. > 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_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" > (instead of putting "OP_TRUE"). > > > There are endless combinations, and even if there will be a rule to evaluate > 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 include > spam on-chain. So, the question is: how strict should those rules be? > > > "I disapprove of what you say, but I will defend to the death your right to > > say it." > > > 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 that is > needed, is just proving they existed, and that they are connected to a > certain transaction (so, it is about timestamping, not about storage). > > 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 can > support OP_CHECKSIG. To validate such commitment, all that is needed, is > converting R-value of a signature into the Taproot address, and then checking > if a given commitment matches such key. > > > I agree with Peter that, given that users have found ways to store > > arbitrary amounts of data on-chain if they really want, we might as well > > just make OP_RETURN a free-for-all. > > > I think we should go in the opposite direction. Using OP_RETURN means that > all nodes will store such data. Using witness means that only witness nodes > 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 should 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. > > On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Hi Bitcoin Developers, > > > There is a famous quote attributed to Evelyn Beatrice Hall in her biography > of Voltaire: "I disapprove of what you say, but I will defend to the death > your right to say it." I'm curious to know how many Bitcoin developers share > this sentiment. > > Recently there was a lot of enthusiasm on social media to run bitcoin core > with a patch that would reject some transactions in mempool. Bitcoin Knots > already has an option to reject transactions that reuse addresses. What if > such practices become common and some projects that provide easy to use node > software start censoring transactions? How would government agencies take > advantage of this whole drama? > > I understand it is difficult to censor different type of transaction because > 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. > > - Peter Todd had written a [blog post][1] in which counting number of INVs > (step 5,6,7 and 8) helps in testing if your transactions are getting relayed > 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 was > seen on other nodes after broadcasting. > > What would an ideal tool for testing censorship resistance look like? > > - Allows user to construct different types of transactions that might be > considered "bad" by some people. Example: OFAC address in output, > Inscription, 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 probability > of tx getting propagated to miners > > There was even some discussion about an [external mempool][4] that could be > used for non-standard transactions. It could also help in avoiding censorship > in some cases. I welcome your thoughts and feedback on this topic. > > 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 > > /dev/fd0 > floppy disc guy > > Sent with Proton Mail secure email. > > _______________________________________________ > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
