Here is an updated version of my email to the bitcoindev ML, which fixes a typo: Hi list - I was hoping to post this on the PR, but it's still locked so I will post it here. I don't really have any other methods of addressing the public as my X account has also been suspended due to trolls reporting it. I did create a Nostr account, but Nostr doesn't seem to have many users. There is a wild misconception floating around that the BIP I am proposing is a "legal threat from Ocean Mining". This could not be further from the truth, and I suspect this nonsense is being pushed by people who would love to see Bitcoin become a data storage service. I would like to take this opportunity to correct the record. Though I am in direct communication with some Ocean employees (and the BIP was originally drafted by one of them), I am not affiliated with Ocean in any way. I am just a Bitcoin dev who is concerned about the implications of Core 30 having been released and gaining adoption. The references to "legal risks" in the BIP are not "threats". They are warnings about a major legal and moral threat that has been created by Bitcoin Core 30's officially designating Bitcoin as a storage service for files up to 100kB. Specifically, there is an unknown level of risk that node operators could be classified as sex offenders (or some other type of criminals depending on the content) for possessing and distributing toxic content. This threat does not come from me, or from Ocean, but rather from Core 30 and its effect on node operators themselves, their consciences, and the communities in which they live. Core 30 forces every single node operator, from the moment toxic content is posted to the blockchain until the end of time, to be complicit in sexual (or other) crimes via possession and distribution of illegal data. So now that Core 30 is gaining adoption, it's very likely that, given the choice of whether to participate in Bitcoin or not, most normal people will simply choose not to participate, and then Bitcoin becomes just another BSV. If Core had just left the OP_RETURN limit where it was, no significant legal threat would exist, and no consensus changes would be urgently needed. I am not saying "I'm going to sue you if you don't support the fork". That is ridiculous. I am saying "you probably want to support this fork if aiding and abetting sex offenders (and potentially being one yourself) does not appeal to you, and you may not want to run a node once Core 30's new default policies become the standard (which is about to happen)." Most Bitcoiners I know signed up for permissionless money, and believe strongly in the freedom to transact, even for people who do things we don't like, since the vision of a maximally neutral monetary standard is why we're all here in the first place. Because Bitcoin's purpose is to be permissionless money, simply storing and forwarding a record of an "illegal" purchase is acceptable to most node operators, because that is the price of entry for trustless, digital money. Storing and forwarding actual illegal content, in the clear, however, is not a problem Bitcoin was ever intended to solve, nor something in which Bitcoin node operators are interested in participating. Indeed, permissionless censorship-resistant data storage is probably not a sustainable idea, without some kind of periodic payment to the person tasked with storing the data. In any case, forcing all Bitcoin node operators to knowingly commit crimes totally unrelated to the operation of Bitcoin as permissionless money, for the rest of eternity, is obviously a foolish idea and will quickly lead to node centralization and irrelevance if we do not act. Yet this heavy-handed and completely unnecessary imposition is precisely what Core 30 achieves, unless it is enthusiastically opposed by the community. Even in the best case, Core 30's new default policies set a terrible precedent that must be immediately reversed. Since almost all forms of illegal data can be avoided by limiting data fields to 256 bytes, BIP-444 seems like a no-brainer to me, because it neatly dodges the dark fate that awaits us down the data storage path. Having engaged many principled Bitcoiners on this topic for a long time, I can confidently say that Bitcoiners overwhelmingly support keeping Bitcoin as permissionless money, and overwhelmingly oppose Bitcoin's block space being used for data storage. Limiting large data storage in consensus, as BIP-444 does, is the easiest way I can see to give everyone what they want. So even if BIP-444 does not activate in its exact current form, I am dedicating myself to helping Bitcoin re-affirm its commitment to permissionless money while re-affirming its opposition to data storage. I am incorporating all feedback I am hearing (which is a lot!) into the next draft of the BIP. Thanks again to everyone for your thoughtful and respectful engagement on this matter critically important to the future of Bitcoin. Together we will find the way forward. Sincerely, Dathon
To verify this message, you can `curl` it from primal: `curl -s https://primal.net/e/` Then copy the "content" field and parse it like so: `echo | sed 's/ /\n/g' > temp.asc && gpg --verify temp.asc && rm temp.asc`
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Verifying myself as [email protected] -----BEGIN PGP SIGNATURE----- iIoEARYIADIWIQQrl/Ayk3RNcPa7qC8uOmb/Z/mLTwUCaP/G1xQcZGF0aG9ub2ht QHByb3Rvbi5tZQAKCRAuOmb/Z/mLT31oAP4jrjT30FW0jcZO4B3qdZr10Tkongzw FDKZcRtjliLpFgEA8/AeEqAbetOer3TWKZc5aDfZl+ajuptYFN+1MRCdFgU= =5ipW -----END PGP SIGNATURE-----
My GPG key can be installed like so: curl -s https://api.github.com/users/dathonohm/gpg_keys | jq -r '.[0].raw_key' | gpg --import
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Verifying myself as [email protected] and https://github.com/dathonohm -----BEGIN PGP SIGNATURE----- iIoEARYIADIWIQQrl/Ayk3RNcPa7qC8uOmb/Z/mLTwUCaP/ACxQcZGF0aG9ub2ht QHByb3Rvbi5tZQAKCRAuOmb/Z/mLT71PAQDEEXfVmQKrWm1F5qT8PsTOZLZjmeJr 0h9JRV/Q2qM+agD/W4BjlFMXRiYoN65vxGByzl8+0iTs9KMwOHNBN7uhjQg= =3jdv -----END PGP SIGNATURE-----
Welcome to Dathon Ohm spacestr profile!
About Me
GPG: 0x2E3A66FF67F98B4F
Interests
- No interests listed.