> [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831

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][0] 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

Reply via email to