Sovran Systems

Zero-JS Hypermedia Browser

avatar
Sovran Systems
founder@zaps.sovransystems.com
npub1z3r2...zmvf
Be Digitally Sovereign! The computer movement where we make it easy to run your own Bitcoin/Lightning Node, private Bitcoin point of sale, private cloud, private messaging with voice and video calling, private website hosting, and private Bitcoin buying and selling to name a few all on one device called the Sovran Pro.

Notes (17)

Mempool policy is just as important as consensus! If a group of people change the mempool policy they are the attackers and attackers have no place in this community.
2025-10-16 11:05:15 from 1 relay(s) View Thread →
Fuck v30 was released. Fuckers.
2025-10-12 16:17:28 from 1 relay(s) View Thread →
We stack the sats, we run the Knots! We then win! cOrE v30 has not been released as of this note's date. Congrats to alll the toxic giga chads for not backing down!!! Fuck the mempool policy attackers. Go pound sand and get the fuck out of our community! We don't want you here ever again!
2025-10-12 02:45:24 from 1 relay(s) View Thread →
The Timechains consensus is agnostic to data type. LET ME REPEAT -consensus is agnostic to data type. The only filter systems in Bitcoin are the mempool policies. Mempool polices are the only system in place to keep non-monetary data off the Timechain. Any group of people that want to fuck with node mempool policies are ENEMIES to Bitcoin! So any fucker who tries to start an argument for the stupid technical argument that it aligns with "consensus" is literately saying mempool polices be damned. Mempool polices are the only and thus extremely important guard against the ideologies that are not aligned to the True Bitcoin ethos! Mempool polices are just as important as consensus!!!
2025-10-10 21:45:48 from 1 relay(s) View Thread →
Why the the FUCK!!! If this is because of cOrE v30 devs, you all should never be allowed back into this community, ever!! image
2025-10-10 21:22:50 from 1 relay(s) View Thread →
I hope this is not because of cOrE v30... image
2025-10-10 21:00:44 from 1 relay(s) View Thread →
Since Bitcoin's consensus rules do not restrict non-monetary data on the blockchain (as discussed previously), mempool policies—node-specific filters for transaction relay and acceptance—serve as the primary mechanism to limit such data from propagating widely and entering blocks. For instance, traditional policies capped OP_RETURN outputs (a common way to embed arbitrary data) at 83 bytes and limited them to one per transaction, discouraging spam or bloat by making these transactions harder to relay across the network. Without these policies, valid transactions with excessive non-monetary data could flood mempools more easily, increasing the likelihood of inclusion by miners. However, policies are not absolute barriers: miners can still directly include consensus-valid transactions with such data if they choose, though this is rare due to relay challenges and economic incentives. Recent changes in Bitcoin Core (as of the October 2025 release) have relaxed the default OP_RETURN limit in policies, shifting more reliance toward miner discretion and user fees to manage data growth. In essence, mempool filtering remains essential for practical control over the timechain's composition.
2025-10-10 03:26:25 from 1 relay(s) View Thread →
Questions: With his understanding.... "Bitcoin's blockchain (often referred to as the "timechain" due to its timestamping function) is fundamentally agnostic to the content of the data embedded in transactions, provided they adhere to the protocol's structural rules—like valid UTXO (Unspent Transaction Output) consumption and creation, proper cryptographic signatures, and fitting within the block weight limit (currently around 4 million weight units post-SegWit, equivalent to roughly 1-4 MB depending on transaction types). The network doesn't interpret or restrict the semantic meaning of the data; it simply validates the transaction's format and ensures no double-spends or invalid spends occur. This agnosticism enables various use cases for embedding arbitrary data, such as: OP_RETURN outputs: These allow up to 80 bytes of non-spendable data (e.g., text, hashes, or metadata) attached to a valid transaction, explicitly designed for this purpose without affecting UTXO set bloat. Script-based embedding: Data can be hidden in locking/unlocking scripts, multisig dummy outputs, or even the coinbase transaction (miners' reward input). SegWit witness data: Post-2017 upgrade, extra data can be stored in the witness field, which doesn't count toward the base block size limit. While this flexibility has sparked debates about chain bloat (e.g., from NFTs via Ordinals or large inscriptions), the protocol itself imposes no content-based filters beyond the mentioned caveats—miners choose what to include based on fees, and full nodes enforce only consensus rules. If data violates size limits or transaction validity, it's rejected, but otherwise, the blockchain treats it as neutral payload." It is imperative that the mempool policies enforce the culture of the Bitcoin ethos. Therefore, the node runners play a very important part in keeping spam off the timechian as they are one of only a few regulators keeping content that is out side the scope of monetary transactions from being cemented for a thousand years.
2025-10-10 01:37:02 from 1 relay(s) View Thread →
After reading through the corev30 technical arguments.... I still land on NOT updating to v30 and using Knots. I do agree with this... image
2025-10-09 22:46:56 from 1 relay(s) View Thread →
Please create a github account and comment on this stating to not release this PR. Down vote it. Every comment and down vote helps. Also, it will show publicly you do not support it which will help legally if you would run your own node in the future. https://github.com/bitcoin/bitcoin/issues/32275
2025-10-09 13:55:03 from 1 relay(s) View Thread →
Question: Does setting the OP_RETURN limit to 40bytes in Knots filter out both the mempool and blockchain OP_RETURN or just the mempool OP_RETURN? Thanks!
2025-10-03 14:17:57 from 1 relay(s) View Thread →