mike's avatar
mike mike@mikehardcastle.com 8 months ago
GM, It's 639am UK time, and I didn't sleep much last night. I got up to write this, then I'm going back to bed, I still won't sleep much. First of all, thank you Will, for all you do, both on Core and on NOSTR. I don't do much myself, but I have done my fair share to change the world in my life. I am mostly a passenger now, but I promise I have earned my position at the top table for oversight of the world as it changes. Once again, I deeply respect and admire you and everything you do. My understanding of your statement is you can do this anyway via another method, so what’s the problem allowing this to happen via OP_RETURN. This is bad, please allow me to set out my stall. I don’t want to store cat JPEGs or inscribed love letters on my nodes. Bitcoin is a financial transaction system, that is all. I appreciate it has always been possible to inscribe data on the blockchain from the genesis blocks “Banks on Brink of second collapse” to Len Sassaman’s ASCII art image. But taproot, in an effort to optimise storage and move closer towards a Turing complete engine by creating and combining scripts within Merkle trees, gave an unintended consequence. Cat JPEGs stored natively on the blockchain. This exists, we can’t stop it, many parties, including miners and NFT artists want this. I don’t. Let Ethereum have the monopoly on cat JPEGs, I’m not looking to compete with Ethereum. That is my 3 - 5 votes out of 20,000+ active nodes at any time. So, we are here, we have cat JPEGs and we have love poems stored on the blockchain, so allowing love poems in the OP_RETURN doesn’t matter because we can do this anyway. I disagree. For me we need to be making it harder to store cat JPEGs and love poems, not easier and continue to do this granularly until it is eliminated. That is the direction I want to head in. So my question is, what can’t we do with the blockchain that we would be able to do with an unrestricted OP_RETURN. If you don’t know the answer, that’s fine, just because you’re a core developer doesn’t give you the ability to read somebody else’s mind. The other argument I’ve seen from Lopp is that he has a lot of Bitcoin and not much shareholding in Citrea, the company pushing for this change. Why would he damage his Bitcoin for such a small company. This argument also, doesn’t hold water. Nobody expected Taproot would allow anybody to store cat JPEGs, the unintended consequences of change is always there. I am in no way a developer, but I did code back in the 1980’s to early 90’s. I built, ran and maintained a Hungarian mainframe called a VT6000 based on Bull Mitre architecture for our global public electronics company, “Densitron”, which my father founded and still exists today inside one of my other companies. The machine ran MMT2 O/S and COBOL compiler. I was one of two people extending the functionality of a global accounting, stock control and ordering system called RelAcs (Real Time Accounting System). My colleague, a Hungarian called Charlie Lugosi was highly skilled, way beyond my limited abilities. We both broke the system in every conceivable way countless times trying to improve or maintain either the machines micro-code, the OS or the applications.The machine had 2 x 300MB CDC disks, 1MB RAM and a 2MB cache. It supported up to 16 dumb terminals. By comparison, modern code like Bitcoin is unimaginably more complex, but the principles still apply. You never fully understand the consequences of a change until it is in production and being used in the real world. Jameson Lopp would absolutely break Bitcoin if it benefitted him, somebody broke Bitcoin to allow cat JPEGs, probably unintentionally. Somebody let a virus out of a lab in China, probably unintentionally. Unless there is a very good reason to reduce the restriction on OP_RETURN size, then we don’t do it, because nobody knows what the consequences of this is, and Bitcoin core developers have no special insights that non core devs don’t. And Bitcoin code, by nature is very conservative. Which is why Taproot caused more problems than it fixed. As a core developer, if you are now involving yourself directly. If you don’t know “why” we want to remove the OP_RETURN limit, you should be finding out, not discussing “well it’s broken anyway, what harm can it do” with idiots like me. I am a voter and a customer and a user of your Core software, I can vote with my node and give my "free" business to other Bitcoin suppliers like Knots. I and my colleagues are who you are working for, albeit selflessly and unpaid. I am the one you are your core colleagues are accountable to. If you are fully open and honest with us, you have our respect, support and admiration, if you treat us like we don't matter, we all leave and you are left in an empty ivory tower.
↑ Parent

Replies (18)

R's avatar
R 8 months ago
This is a respectful response in an interesting conversation. Nostr is the place for this! nevent1qqs8m5exnap3rze9rf4mdaftzlexs8e78xmm96urz3tgf4x6yfe4waslrrh4u
Robertrobert's avatar
Robertrobert padoc2robert@nostrcheck.me 8 months ago
GM☕️☕️🌅💜😱Man this is very impressive reply to the current kerfuffle! I am a nobody, no coder, bitcoin monetary maximalist. Any changes to core should be made to improve this one function which underlies any other protocol function.🫡
1 replies ↓
Melvin Carvalho's avatar
Melvin Carvalho _@melvincarvalho.com 8 months ago
I see both sides here. Taproot had unintended consequences — one of which is Nostr. Nostr identity is based on the Taproot BIP, and it's given Bitcoin the beginnings of a social layer. There’s a difference between maintenance and renovation. You maintain a school by mopping the floors; you renovate it by adding a new door to a corridor. In any system or standard, there’s always a grey area between minor maintenance changes and behaviour-altering changes. At the W3C, we have something called “class 2” changes — used for typos, improved examples, and other edits that don’t affect behaviour. They follow a lightweight process. Larger changes are “class 3” and go through wider review. It’s common to see people try to pass class 3 changes off as class 2 — but the rule is: if there’s disagreement, it’s not class 2. (Of course, who defines disagreement is a whole other problem.) Bitcoin might benefit from a similar distinction: separating maintenance from behavioural changes, and handling them with different levels of review and process. Discussion is always good in these situations.
1 replies ↓
Rico's avatar
Rico rico@nostrpurple.com 8 months ago
I don't see the argument against larger op returns because nobody will track down small miners / pools to have their custom block mined being particularly strong as this is what happens already. Centralization in that regard is the current status quo, whoever wants crazy blocks mined can do it with our without opreturns changes. I could turn the argument around saying that larger op returns would make those custom blocks unnecessary because the goal to host data on the blockchain can be achieved now without such manipulation. But then again, as stated by gmaxwell, there are interest groups who just like to have a block for themselves printing MARA in the mempool.space thumbnail and whatnot and they will AND CAN do it no matter the op return field. How does a larger op return field change that in any way?
Jose Sammut's avatar
Jose Sammut 8 months ago
Im very happy these discussions are happening on nostr. I tend to agree with @mike. We don't know what people will do with this added freedom. If they abuse it in some other new way, would we just regularise that too? What is the most sustainable direction here? That is usually what defines my principle. Thank you all. @jb55 too. View quoted note → #nostr #Bitcoin
mike's avatar mike
GM, It's 639am UK time, and I didn't sleep much last night. I got up to write this, then I'm going back to bed, I still won't sleep much. First of all, thank you Will, for all you do, both on Core and on NOSTR. I don't do much myself, but I have done my fair share to change the world in my life. I am mostly a passenger now, but I promise I have earned my position at the top table for oversight of the world as it changes. Once again, I deeply respect and admire you and everything you do. My understanding of your statement is you can do this anyway via another method, so what’s the problem allowing this to happen via OP_RETURN. This is bad, please allow me to set out my stall. I don’t want to store cat JPEGs or inscribed love letters on my nodes. Bitcoin is a financial transaction system, that is all. I appreciate it has always been possible to inscribe data on the blockchain from the genesis blocks “Banks on Brink of second collapse” to Len Sassaman’s ASCII art image. But taproot, in an effort to optimise storage and move closer towards a Turing complete engine by creating and combining scripts within Merkle trees, gave an unintended consequence. Cat JPEGs stored natively on the blockchain. This exists, we can’t stop it, many parties, including miners and NFT artists want this. I don’t. Let Ethereum have the monopoly on cat JPEGs, I’m not looking to compete with Ethereum. That is my 3 - 5 votes out of 20,000+ active nodes at any time. So, we are here, we have cat JPEGs and we have love poems stored on the blockchain, so allowing love poems in the OP_RETURN doesn’t matter because we can do this anyway. I disagree. For me we need to be making it harder to store cat JPEGs and love poems, not easier and continue to do this granularly until it is eliminated. That is the direction I want to head in. So my question is, what can’t we do with the blockchain that we would be able to do with an unrestricted OP_RETURN. If you don’t know the answer, that’s fine, just because you’re a core developer doesn’t give you the ability to read somebody else’s mind. The other argument I’ve seen from Lopp is that he has a lot of Bitcoin and not much shareholding in Citrea, the company pushing for this change. Why would he damage his Bitcoin for such a small company. This argument also, doesn’t hold water. Nobody expected Taproot would allow anybody to store cat JPEGs, the unintended consequences of change is always there. I am in no way a developer, but I did code back in the 1980’s to early 90’s. I built, ran and maintained a Hungarian mainframe called a VT6000 based on Bull Mitre architecture for our global public electronics company, “Densitron”, which my father founded and still exists today inside one of my other companies. The machine ran MMT2 O/S and COBOL compiler. I was one of two people extending the functionality of a global accounting, stock control and ordering system called RelAcs (Real Time Accounting System). My colleague, a Hungarian called Charlie Lugosi was highly skilled, way beyond my limited abilities. We both broke the system in every conceivable way countless times trying to improve or maintain either the machines micro-code, the OS or the applications.The machine had 2 x 300MB CDC disks, 1MB RAM and a 2MB cache. It supported up to 16 dumb terminals. By comparison, modern code like Bitcoin is unimaginably more complex, but the principles still apply. You never fully understand the consequences of a change until it is in production and being used in the real world. Jameson Lopp would absolutely break Bitcoin if it benefitted him, somebody broke Bitcoin to allow cat JPEGs, probably unintentionally. Somebody let a virus out of a lab in China, probably unintentionally. Unless there is a very good reason to reduce the restriction on OP_RETURN size, then we don’t do it, because nobody knows what the consequences of this is, and Bitcoin core developers have no special insights that non core devs don’t. And Bitcoin code, by nature is very conservative. Which is why Taproot caused more problems than it fixed. As a core developer, if you are now involving yourself directly. If you don’t know “why” we want to remove the OP_RETURN limit, you should be finding out, not discussing “well it’s broken anyway, what harm can it do” with idiots like me. I am a voter and a customer and a user of your Core software, I can vote with my node and give my "free" business to other Bitcoin suppliers like Knots. I and my colleagues are who you are working for, albeit selflessly and unpaid. I am the one you are your core colleagues are accountable to. If you are fully open and honest with us, you have our respect, support and admiration, if you treat us like we don't matter, we all leave and you are left in an empty ivory tower.
View quoted note →
supermass's avatar
supermass 8 months ago
“I disagree. For me we need to be making it harder to store cat JPEGs and love poems, not easier and continue to do this granularly until it is eliminated. That is the direction I want to head in.” 🎯 CULTURAL ISSUE, NOT TECHNICAL. And the Core people don’t care. nevent1qqs8m5exnap3rze9rf4mdaftzlexs8e78xmm96urz3tgf4x6yfe4waslrrh4u
Default avatar
npub1wvtl...jhd0 8 months ago
Why make out they want this for cat JPEGs. It's about contracts for bridges right? What option is going to limit the ability to have permissionless money the most? If bridges need to contact miners directly, then only bridges that are in the interest of the majority of mining power get in. Other things, like privacy chains that are banned by the state will be rejected out of fear of prosecution. Cat JPEGs are already there with a segwit witness discount. They don't need this to bloat the chain and put pressure on decentralisation of node running. As the OP points out, currently large miners are being contacted directly to include these transactions, this works against mining decentralisation. By all means think through the consequences, but be honest when weighing up the positives and negatives. The current state of play limits bridges to white listed entities and mining centralisation. Appealing to the boogie man what if and cat JPEGs is not a strong argument.
1 replies ↓
S!ayer's avatar
S!ayer 8 months ago
Mike came off the boat swinging
mike's avatar mike
GM, It's 639am UK time, and I didn't sleep much last night. I got up to write this, then I'm going back to bed, I still won't sleep much. First of all, thank you Will, for all you do, both on Core and on NOSTR. I don't do much myself, but I have done my fair share to change the world in my life. I am mostly a passenger now, but I promise I have earned my position at the top table for oversight of the world as it changes. Once again, I deeply respect and admire you and everything you do. My understanding of your statement is you can do this anyway via another method, so what’s the problem allowing this to happen via OP_RETURN. This is bad, please allow me to set out my stall. I don’t want to store cat JPEGs or inscribed love letters on my nodes. Bitcoin is a financial transaction system, that is all. I appreciate it has always been possible to inscribe data on the blockchain from the genesis blocks “Banks on Brink of second collapse” to Len Sassaman’s ASCII art image. But taproot, in an effort to optimise storage and move closer towards a Turing complete engine by creating and combining scripts within Merkle trees, gave an unintended consequence. Cat JPEGs stored natively on the blockchain. This exists, we can’t stop it, many parties, including miners and NFT artists want this. I don’t. Let Ethereum have the monopoly on cat JPEGs, I’m not looking to compete with Ethereum. That is my 3 - 5 votes out of 20,000+ active nodes at any time. So, we are here, we have cat JPEGs and we have love poems stored on the blockchain, so allowing love poems in the OP_RETURN doesn’t matter because we can do this anyway. I disagree. For me we need to be making it harder to store cat JPEGs and love poems, not easier and continue to do this granularly until it is eliminated. That is the direction I want to head in. So my question is, what can’t we do with the blockchain that we would be able to do with an unrestricted OP_RETURN. If you don’t know the answer, that’s fine, just because you’re a core developer doesn’t give you the ability to read somebody else’s mind. The other argument I’ve seen from Lopp is that he has a lot of Bitcoin and not much shareholding in Citrea, the company pushing for this change. Why would he damage his Bitcoin for such a small company. This argument also, doesn’t hold water. Nobody expected Taproot would allow anybody to store cat JPEGs, the unintended consequences of change is always there. I am in no way a developer, but I did code back in the 1980’s to early 90’s. I built, ran and maintained a Hungarian mainframe called a VT6000 based on Bull Mitre architecture for our global public electronics company, “Densitron”, which my father founded and still exists today inside one of my other companies. The machine ran MMT2 O/S and COBOL compiler. I was one of two people extending the functionality of a global accounting, stock control and ordering system called RelAcs (Real Time Accounting System). My colleague, a Hungarian called Charlie Lugosi was highly skilled, way beyond my limited abilities. We both broke the system in every conceivable way countless times trying to improve or maintain either the machines micro-code, the OS or the applications.The machine had 2 x 300MB CDC disks, 1MB RAM and a 2MB cache. It supported up to 16 dumb terminals. By comparison, modern code like Bitcoin is unimaginably more complex, but the principles still apply. You never fully understand the consequences of a change until it is in production and being used in the real world. Jameson Lopp would absolutely break Bitcoin if it benefitted him, somebody broke Bitcoin to allow cat JPEGs, probably unintentionally. Somebody let a virus out of a lab in China, probably unintentionally. Unless there is a very good reason to reduce the restriction on OP_RETURN size, then we don’t do it, because nobody knows what the consequences of this is, and Bitcoin core developers have no special insights that non core devs don’t. And Bitcoin code, by nature is very conservative. Which is why Taproot caused more problems than it fixed. As a core developer, if you are now involving yourself directly. If you don’t know “why” we want to remove the OP_RETURN limit, you should be finding out, not discussing “well it’s broken anyway, what harm can it do” with idiots like me. I am a voter and a customer and a user of your Core software, I can vote with my node and give my "free" business to other Bitcoin suppliers like Knots. I and my colleagues are who you are working for, albeit selflessly and unpaid. I am the one you are your core colleagues are accountable to. If you are fully open and honest with us, you have our respect, support and admiration, if you treat us like we don't matter, we all leave and you are left in an empty ivory tower.
View quoted note →
Default avatar
npub12e8a...9crf 8 months ago
Entao desceram os amalequitas e os cananeus, que habitavam na montanha, e os feriram, derrotando-os ate Horma. #Entao #desceram #os #amalequitas #e #os #cananeus, #que #habitavam #na #montanha, #e #os #feriram, #derrotando-os #ate #Horma. Luego descendieron a los amalequitas y a los cananeos, que habitaban la montaa, y los hirieron, derrotndolos a Horma. #Luego #descendieron #a #los #amalequitas #y #a #los #cananeos, #que #habitaban #la #montaa, #y #los #hirieron, #derrotndolos #a #Horma. Ensuite, ils sont descendus les Amalequites et les Cananens, qui habitaient la montagne, et les ont blesss, les battant Horma. #Ensuite, #ils #sont #descendus #les #Amalequites #et #les #Cananens, #qui #habitaient #la #montagne, #et #les #ont #blesss, #les #battant # #Horma. Quindi scendettero gli Amalequiti e i Cananei, che abitavano la montagna e li ferirono, sconfiggendoli con Horma. #Quindi #scendettero #gli #Amalequiti #e #i #Cananei, #che #abitavano #la #montagna #e #li #ferirono, #sconfiggendoli #con #Horma. Then they descended the Amalequites and the Canaanites, who inhabited the mountain, and wounded them, defeating them to Horma. #Then #they #descended #the #Amalequites #and #the #Canaanites, #who #inhabited #the #mountain, #and #wounded #them, #defeating #them #to #Horma. Dann stiegen sie die Amalquiten und die Kanaaniter ab, die den Berg bewohnten, und verwundeten sie und besiegten sie zu Horma. #Dann #stiegen #sie #die #Amalquiten #und #die #Kanaaniter #ab, #die #den #Berg #bewohnten, #und #verwundeten #sie #und #besiegten #sie #zu #Horma. Kisha wakashuka Waamalequites na Wakanaani, ambao walikaa mlima, na kuwajeruhi, wakawashinda kwa Horma. #Kisha #wakashuka #Waamalequites #na #Wakanaani, #ambao #walikaa #mlima, #na #kuwajeruhi, #wakawashinda #kwa #Horma. Kemudian mereka turun ke Amalequites dan orang Kanaan, yang mendiami gunung, dan melukai mereka, mengalahkan mereka untuk Horma. #Kemudian #mereka #turun #ke #Amalequites #dan #orang #Kanaan, #yang #mendiami #gunung, #dan #melukai #mereka, #mengalahkan #mereka #untuk #Horma.
mike's avatar
mike mike@mikehardcastle.com 8 months ago
This is my take: nevent1qvzqqqqqqypzp6pmv65w6tfhcp73404xuxcqpg24f8rf2z86f3v824td22c9ymptqyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccsqgra6vnf7sc33vj356ak75430ungrulrndajawp3g45y6ndzyu6hwch652na
1 replies ↓
mike's avatar
mike mike@mikehardcastle.com 7 months ago
They are removing the 80 character limit on OP_RETURN on Core, these are my thoughts: nevent1qvzqqqqqqypzp6pmv65w6tfhcp73404xuxcqpg24f8rf2z86f3v824td22c9ymptqyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccsqgra6vnf7sc33vj356ak75430ungrulrndajawp3g45y6ndzyu6hwch652na
mike's avatar
mike mike@mikehardcastle.com 7 months ago
The Bitcoin core devs are making changes that do not benefit Bitcoin. Here is some history from myself and others if you want to know more: nevent1qvzqqqqqqypzp6pmv65w6tfhcp73404xuxcqpg24f8rf2z86f3v824td22c9ymptqyv8wumn8ghj7enfd36x2u3wdehhxarj9emkjmn99uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcprfmhxue69uhhyetvv9ujuem9w3skccne9e3k7mf0wccsqgra6vnf7sc33vj356ak75430ungrulrndajawp3g45y6ndzyu6hwch652na nevent1qvzqqqqqqypzpprrqa5g5z0vzy5k06c9gnnc485gcj84qufv88k5j8ljkmaqrxhgqy8hwumn8ghj7mn2w4khqtndv5hszythwden5te0dehhxarj9ekxzmny9uqzqvjuuget8yrmhphpp2y9lcj6dd8gfeqd7eh9cfmc5exzh6njlawva7tza6 nevent1qvzqqqqqqypzqpxfzhdwlm3cx9l6wdzyft8w8y9gy607tqgtyfq7tekaxs7lhmxfqqsg0ewq767afwyzhcp6gnmxyrutcvuzy3h2d2y8pvwugn0h6hp8fcq6ve5r3
3 replies ↓
↑