Right! You are one of those:
https://github.com/bitcoin/bips/pull/1408#issuecomment-1566168000
Where should this topic be addressed? Where is it the most effective way or medium?
nostr:note15w85equw7vfdgf2nm4j86twzjgptje9xg86t2dntv68tyg4cy44srkld2j
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk: Is there a list of who are the participants of that “developer mailings list”? So far I have not read any comment regarding the relevant aspects of this topic.
Different than nostr:npub1ywjjp4dup38veklgw44p2d24n9yze8e4u4gpxwm49ka6rjvyu9dsfg6ejf‘s ones of course.
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk: Is there a list of who are the participants of that “developer mailings list”? So far I have not read any comment regarding the relevant aspects of this topic.
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
Satoshi: “That's one of the reasons for transaction fees. There are other things we can do if necessary.”
What would be the other things we could do? Were all the things we could do already implemented or thought?
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk:
Did Satoshi ever answer following comment:
“
This is interesting, and is a possible way to embed messages inside anonymous payments, at the cost of transaction fees.
So if a payment contains a No-op string that says "Message encrypted for Public Key [xxx]: [yyyyy]" then that gets passed along to the destination? Or even "Cleartext message to recipient: [zzzzz]."
Of course the content of these messages - the [xxx] or [yyyyy] have nothing to do with Bitcoin, but they could be used as part of a layer on top of Bitcoin.
The reason I'm so interested in embedding messages is that they allow use of a "static" anonymity network like Freenet, rather than a "live" network like Tor or I2P. Live networks have exit nodes, a few of which can be compromised. If a government compromises 1% of all exit nodes, then they have a small chance of figuring out where a given site is hosted. So to use my Heroin Store example, they would send an N byte message to the store and watch all of their compromised exit nodes for N byte messages. They'd do this over a few hours, watching where N byte messages got sent to, eventually discovering the IP address of the store.
In a network like Freenet, data just floats around - there is no one machine where a website (for example) lives. You publish data to the cloud, and as long as people access it periodically, it stays around.
“
At that time the ones providing, with theirs nodes, storage and computational mining activities resources also got the chance to obtain compensation via fees. Nowadays that is not the case and the ones providing only storage resources (aka. archival-full-node or better named regular Bitcoin node) do not receive compensation at all; thus no monetary economical incentives to run a regular Bitcoin node exists.
In case regular Bitcoin nodes diminish in numbers spread around the globe, then the “decentralization” and control will be taken by big mining pools or central entities; uniting the storage and mining activities again in one single original Bitcoin node or in its defect, the most important feature of the Bitcoin System - it’s decentralization - will be destroyed and that would make it not different from any other altcoin network existing nowadays.
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
From your point of view and experience; what is or would be the ugly things which Satoshi was referring to?
Satoshi: “This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.”
At his/her/their active pseudo-public time the original Bitcoin node was performing mining activities and the ugly things which I could think about would be chain-splits and chain reorganizations.
Nowadays regular Bitcoin nodes do not perform mining activities. So, what could be those ugly things that could happen with minority and majority numerical running node behavior versions?
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
Satoshi: “That's one of the reasons for transaction fees. There are other things we can do if necessary.”
What would be the other things we could do? Were all the things we could do already implemented or thought?
Well no, in fact he does. He acknowledges the soverengty of the spammers, but not of the defenders 💩
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
From your point of view and experience; what is or would be the ugly things which Satoshi was referring to?
Satoshi: “This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.”
At his/her/their active pseudo-public time the original Bitcoin node was performing mining activities and the ugly things which I could think about would be chain-splits and chain reorganizations.
Nowadays regular Bitcoin nodes do not perform mining activities. So, what could be those ugly things that could happen with minority and majority numerical running node behavior versions?
nostr:note1ddqkjcg984v3urlmwcs3nrar7c5plzkzfgxykx4kd5rnu68j4wvq6v4d78
nostr:note1ynplepaueuuaur8ra7hehdwrkrlshq29f4hr3xr83ytg6y4mmf0qm7vgp0
nostr:note1r32zmzax4n74ryexk46zgun8y7vlg4pqcpwwks0j8grs4u9yvzmstksc6jnostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub100mahqlhxg50thmt5dyynu40nl25hat9kkkknzk8pqjfkvgq0xsqtdfyy5
Why insertion of arbitrary data is an action which should be discouraged? It is because it threats with the most important feature of the Bitcoin System and that is “node decentralization”. Incrementing the operation cost for a Bitcoin regular node (aka. archival-full-node) reduces the adoption of people to run one (running a node does not provide monetary profit; fact which appeared after the separation of mining activity from the original “Bitcoin node”). Therefore, taking into account, that nowadays no monetary incentives exists running a node and, that it represent a resource cost running one, each marginal cost increment has a potential consequence of marginal node decentralization reduction. (Relaying on the technological development and production in the field of solid state storage devices is not sufficient since its rate is not guaranteed to be gather than the fiat dilution rate and the merchant and producer adoption of bitcoin as payment probably would take some time; and that adoption would depend on the Bitcoin regular node decentralization).
nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk nostr:npub100mahqlhxg50thmt5dyynu40nl25hat9kkkknzk8pqjfkvgq0xsqtdfyy5
Following that answer’s rationale, then the past implementation of numerous Bitcoin Core Client policy rules were a waste; yet history has shown, having those options (optionality for economical node operators) enables the possibility of anti-fragility emergence.
While Bitcoin System is permissionless (and that’s a desired feature which provides a value proposition), it is all about incentives and disincentives; encouragements and discouragements.
nostr:npub100mahqlhxg50thmt5dyynu40nl25hat9kkkknzk8pqjfkvgq0xsqtdfyy5 nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
That would be a reason why #Ordislow could be a solution. Since the Bitcoin mempool fee auction seams not to address effectively against dust and insertion of arbitrary data on discount via witness (at least on the short and medium term), #Ordislow could represent a discouragement (and not censorship) to create and process those kind of transactions.
That discouragement via #Ordislow could equilibrate the incentive created by #SegWit.
New kinds of bypassing could easily be detected and addressed by adjustment mechanism (code update or similar) since detection is factor easier than creating a path for bypassing.
That kind of “cat and mouse game” could open a way how Bitcoin System could detect and address its weaknesses; thus meaning it anti-fragiler.
*making it
nostr:npub100mahqlhxg50thmt5dyynu40nl25hat9kkkknzk8pqjfkvgq0xsqtdfyy5 nostr:npub1lh273a4wpkup00stw8dzqjvvrqrfdrv2v3v4t8pynuezlfe5vjnsnaa9nk
That would be a reason why #Ordislow could be a solution. Since the Bitcoin mempool fee auction seams not to address effectively against dust and insertion of arbitrary data on discount via witness (at least on the short and medium term), #Ordislow could represent a discouragement (and not censorship) to create and process those kind of transactions.
That discouragement via #Ordislow could equilibrate the incentive created by #SegWit.
New kinds of bypassing could easily be detected and addressed by adjustment mechanism (code update or similar) since detection is factor easier than creating a path for bypassing.
That kind of “cat and mouse game” could open a way how Bitcoin System could detect and address its weaknesses; thus meaning it anti-fragiler.
nostr:note1r32zmzax4n74ryexk46zgun8y7vlg4pqcpwwks0j8grs4u9yvzmstksc6j
Probably get a bigger capacity SSD
(1.600.000.000.000 bytes)
Or to get inspiration from an #Ordislow implementation in Knots, which Bitcoin regular node operators can take or code in theirs node software client. ☺️
nostr:npub100mahqlhxg50thmt5dyynu40nl25hat9kkkknzk8pqjfkvgq0xsqtdfyy5
Or to provide hints and tuition where in code to look, to consider and maybe to look at the proposed coded code as competent reviewer to avoid additional bug introduction. ☺️