Recently I was writing a historical analysis of what influential devs in bitcoin's past said it is "for," in the expectation that I would find a past consensus that bitcoin nodes are designed to support monetary use of bitcoin and "not" the storage and relay of arbitrary data. And that is mostly what I've found so far, but I did find one notable counterexample:
In 2012, bip37 was deployed, and it includes a line about how it modified bitcoin so that nodes could more easily help SPV clients find and download transactions containing "data elements in either inputs or outputs." It explicitly did this in order to support "various forms of smart property," i.e. assets other than bitcoin, which many bitcoiners (including me) now consider a spammy use of bitcoin's blockchain.
So I have to concede that in 2012 there were bitcoin devs who thought it was okay to use bitcoin nodes for non-monetary purposes, and they even modified bitcoin to provide better support for that. But there is evidence that by 2014 that was no longer considered wise.
Specifically, BIP81 tried to build on the "Smart Property" idea by providing a standardized way for wallet devs to implement support for non-bitcoin assets that got embedded into bitcoin's blockchain via "colored coins" protocols, and that BIP is now considered Closed, i.e. "not being actively worked on, promoted or in active use." This is the category bips are moved to if they never get to "Deployed."
Moreover, while BIP37 supported scanning for "inscription-like" arbitrary data in the scriptSig, when segwit was deployed in 2017, the bloom filter functionality was deliberately not updated to scan for similar data in the witness stack: "BIP 37 was deliberately never updated to support witness-based filtering as newer wallets are expected to migrate to some yet-to-be-network-exposed filters." https://github.com/bitcoin/bitcoin/pull/16152
That quote comes from the pull request that *disabled* bloom filter support on bitcoin nodes by default, and its reference to future filters is a reference to bip157 filters. Those filters explicitly *do not* test for inscription-like data-pushes on the witness stack, the witness script, or the scriptsig. Moreover, they do not test for op_return data either, which bip37 filters "did" test for. So bip37's "replacement" modifies bitcoin back to how it was before bip37: no default support for sharing arbitrary data via SPV-style functionality.
In 2012, bip37 was deployed, and it includes a line about how it modified bitcoin so that nodes could more easily help SPV clients find and download transactions containing "data elements in either inputs or outputs." It explicitly did this in order to support "various forms of smart property," i.e. assets other than bitcoin, which many bitcoiners (including me) now consider a spammy use of bitcoin's blockchain.
So I have to concede that in 2012 there were bitcoin devs who thought it was okay to use bitcoin nodes for non-monetary purposes, and they even modified bitcoin to provide better support for that. But there is evidence that by 2014 that was no longer considered wise.
Specifically, BIP81 tried to build on the "Smart Property" idea by providing a standardized way for wallet devs to implement support for non-bitcoin assets that got embedded into bitcoin's blockchain via "colored coins" protocols, and that BIP is now considered Closed, i.e. "not being actively worked on, promoted or in active use." This is the category bips are moved to if they never get to "Deployed."
Moreover, while BIP37 supported scanning for "inscription-like" arbitrary data in the scriptSig, when segwit was deployed in 2017, the bloom filter functionality was deliberately not updated to scan for similar data in the witness stack: "BIP 37 was deliberately never updated to support witness-based filtering as newer wallets are expected to migrate to some yet-to-be-network-exposed filters." https://github.com/bitcoin/bitcoin/pull/16152
That quote comes from the pull request that *disabled* bloom filter support on bitcoin nodes by default, and its reference to future filters is a reference to bip157 filters. Those filters explicitly *do not* test for inscription-like data-pushes on the witness stack, the witness script, or the scriptsig. Moreover, they do not test for op_return data either, which bip37 filters "did" test for. So bip37's "replacement" modifies bitcoin back to how it was before bip37: no default support for sharing arbitrary data via SPV-style functionality.
22❤️5👀3👍1🚀1🫡1
