How to apply recursive snarks for a fully scalable, fully private, currency

From the very beginning of bitcoin, people worried that it could not scale to the required size.

It does not scale because it is a massively replicated public ledger. Thus any real solution means making the ledger not public. Which means either centralization, a central bank digital currency, which is the path Ethereum is walking, or privacy. You cure both blockchain bloat and blockchain analysis by not putting the data on the reliable public broadcast channel in the first place, rather than doing what Monero does, putting it on the blockchain in cleverly encrypted form, bloating the blockchain with chaff intended to obfuscate against blockchain analysis.

I have for some time remarked that recursive snarks make a fully private, fully scalable, currency, possible. But it seems this was not obvious to everyone, and I see recursive snarks being applied in complicated convoluted stupid ways that fail to utilize their enormous potential. This is in part malicious, the enemy pouring mud into the tech waters. So I guess need to explain.

A zk-snark or a zk-stark proves that someone knows something, knows a pile of data that has certain properties, without revealing that pile of data. Such that he has a preimage of a hash that has certain properties – such as the property of being a valid transaction. You can prove an arbitrarily large amount of data with an approximately constant sized recursive snark.

A recursive snark is a zk-snark that proves that the person who created it has verified a zk-stark that proves that someone has verified a zk-snark that proves that someone has verified …

This explanation is going to require you to know what a graph, vertex, edge, root, and leaf is, what a directed acyclic graph is, what a hash is, what a blockchain is, and how hashes make blockchains possible. And what an sql index is and what it does, and what a primary sql index is and what it does. You need to know what a transaction output is in the context of blockchains, and what an unspent transaction output (utxo) is. Other terms will be briefly and cryptically explained as necessary. All the crypto shills must do the homework that they have been so egregiously neglecting, or else will be silently blocked. I am heartily sick of crypto shills confidently dumping scripts prepared for them by scriptwriters almost as stupid and ignorant as themselves.

A struct is simply some binary data laid out in well known and agreed format. Almost the same thing as an sql row, except that an sql row does not have a well known and agreed binary format, so does not have a well defined hash, and a struct is not necessarily part of an sql table, though obvious you can put a bunch of structs of the same type in an sql table, and represent an sql table as a bunch of structs, plus at least one primary index. An sql table is equivalent to a pile of structs, plus at least one primary index of those structs.

A merkle graph is a directed acyclic graph whose vertices are structs containing hashes

A merkle vertex is a struct containing hashes. The hashes are the edges of the graph. So using recursive snarks over a merkle graph, each vertex has a proof that proved that its data was valid, given that the vertices that its edges point to were valid, and that the peer that created the recursive snark of that vertex verified the recursive snarks of the vertices that the outgoing edges (hashes) of this vertex points to.

So, you have a merkle chain of blocks, each block containing a merkle patricia tree of merkle dags. You have a recursive snark that proves the chain, and everything in it, is valid (no one created tokens out of thin air, each transaction merely moved the ownership of tokens) And then you prove that the new block is valid, given that rest of the chain was valid, and produce a recursive snark that the new block, which chains to previous block, is valid.

A blockchain is a merkle chain and a reliable broadcast channel. In Bitcoin the merkle vertices are very large, each block is a single huge merkle vertex, and each block lives forever on an ever growing public broadcast channel. It is impractical to produce a recursive snark over such huge vertices, and attempting to do so results in centralization, with the recursive snarks being created in a few huge data centers. So we need to structure the data as large dag of small merkle vertices, with all the paths through the dag for which we need to generate proofs being logarithmic in the size of the dag.

A merkle patricia tree is a representation of an sql index as a merkle tree. Each edge of a vertex is associated with a short bitstring, and as you go down the tree from the root (tree graphs have their root at the top and their leaves at the bottom, just to confuse the normies) you append that bitstring, and when you reach the edge (hash) that points to a leaf, you have a bitstring that corresponds to path you took through the merkle tree, and to the leading bits of the bitstring that make that key unique in the index.

So a merkle patricia tree and the structs that its leaf edges point to is an sql table that you can generate recursive snarks for, which can prove things about new transactions to be added to that table. We are unlikely to be programming the blockchain in sql, but to render what one is doing intelligible, it is useful to think and design in sql.

So with recursive snarks you can prove that that your transaction is valid because certain unspent transaction outputs were in the sql index of unspent transaction outputs, and were recently spent in the index of commitments to transactions, without revealing which outputs those were, or what was in your transaction.

It is a widely shared public index. But what it is an index of is private information about the transactions and outputs of those transactions, information known only to the parties of those transactions. It is not a public ledger. It is a widely shared public sql index of private ledgers. And because it is a merkle tree, it is possible to produce a single reasonably short recursive snark for the current root of that tree that proves that every transaction in all those private ledgers was a valid transaction.

Oops, what I just described is a whole sequence of complete immutable sql indexes, each new block a new complete index. But that would waste a whole lot of bandwidth. What you want is that each new block is only an index of new unspent transaction outputs, and of newly spent transaction outputs, which spending events will give rise to new unspent transaction outputs in later blocks, and that this enormous pile of small immutable indexes gets summarized as single mutable index, which gets complicated. I will get to that later – how we purge the hashes of used outputs from the public broadcast channel, winding up with a public broadcast channel that represents a mutable index of an immutable history, with a quite a lot of additional house keeping data that tells how to derive the mutable index from this pile of immutable indices, and tells us what parts of the immutable history only the parties to the transaction need to keep around any more, what can be dumped from the public broadcast channel. Anything you no longer need to derive the mutable index, you can dump.

The parties to a transaction agree on a transaction – typically two humans and two wallets, each wallet the client of a peer on the blockchain.

Those of them that control the inputs to the transaction (typically one human with one wallet which is a client of one peer) commits unspent transactions outputs to that transaction, making them spent transaction outputs. But does not reveal that transaction, or that they are spent to the same transaction – though his peer can probably guess quite accurately that they are.

In the next block that is a descendant of that block the parties to the transaction prove that the new transaction outputs are valid, and being new are unspent transaction outputs, without revealing the transaction or the inputs to that transaction.

You have to register the unspent transaction outputs on the public index, the reliable broadcast channel, within some reasonable time, say perhaps below block height (⌊h/32⌋+2)*32, where h is the block height on which the first commit of an output to the the transaction was registered. If not all the inputs to the transaction were registered, then obviously no one can produce a proof of validity for any of the outputs. After that block height you cannot register any further outputs, but if you prove that after that block height no output of the transaction was registered, you can create a new unspent transaction output for each transaction input to the failed transaction which effectively rolls back the failed transaction. This time limit enables us to recover from failed transactions, and, perhaps, more importantly, enables us to clean up the mutable sql index that the immense chain of immutable sql indexes represents, and that the public broadcast channel contains. We eventually drop outputs that have been committed to a particular transaction, and can then eventually drop the commits of that output without risking orphaning valid outputs that have not yet been registered in the public broadcast channel.

So that the public broadcast channel can eventually dump old blocks, and thus old spend events, every time we produce a new base level block containing new events (an sql index of new transaction outputs, and an sql index table with the same primary of spend commitments of past unspent transaction outputs to transactions) we also produce a consolidation block, a summary block that condenses two past blocks into one summary block, thus enabling the two past blocks that it summarizes to be dropped.

Immediately before forming a block of height 2n+1, which is a block height whose binary representation ends in a one, we use the information in base level blocks 2n-3, 2n-2, 2n-1, and 2n to produces a level one summary block that allows base level blocks 2n-3 and 2n-2, the two oldest remaining base level blocks to be dropped. When we form the block of height 2n+1, it will have an edge to the block of height 2n, forming a chain, and an edge to the summary block summarizing blocks 2n-3 and 2n-2, forming a tree.

At every block height of 4n+2. which is a block height whose binary representation ends in a one followed by a zero, we use the information in the level one summary blocks for heights 4n-5, 4n-3, 4n-1, and 4n+1, to produce a level two summary block that allows the level one summary blocks for 4n-5 and 4n-3, the two oldest remaining lever one summary blocks, to be dropped. The base level blocks are level zero.

At every block height of 8n+4. which is a block height whose binary representation ends in a one followed by two zeroes, we use the information in the level two summary blocks for heights 8n-10, 8n-6, 8n-2, and 8n+2, to produce a level three summary block that allows the level two summary blocks for 8n-10 and 8n-6, the two oldest remaining level two summary blocks, to be dropped.

And similarly, for every block height of 2m+1*n + 2m, every block height whose binary representation ends in a one followed by m zeroes, we use the information in four level m summary blocks to produce a level m+1 summary block than enables the two oldest level m summary blocks to be dropped.

We summarise the data in the earliest two blocks by discarding every transaction output that was, at the time those blocks were created, an unspent transaction output, but is now marked as used in any of the four blocks by committing it to a particular transaction. We discard commits which refer to outputs that have now been discarded by previous summary blocks and have timed out, which is to say, commits in a level m summary block being summarised into a level m+1 summary block that reference outputs in the immediately previous level m+1 summary block. However if, a commit references an output that is now in a summary block of level greater than m+1, that commit has to be kept around to prevent double spending of the previous output, which has not yet been summarised away.

We produce the summary block of past blocks just before we produce the base level block, and the base level block has an edge pointing to the previous base level block, a chain edge, and an edge pointing to the just created summary block a tree edge, a chain edge and a tree edge. And when we summarize two blocks into a higher level summary block, their chain and tree edges are discarded, because pointing to data that the reliable broadcast channel will no longer carry, and the newly created summary block gets a chain edge pointing to the previous summary block at the same level, and tree edge pointing to the previous higher level summary block.

We have to keep the tree around, because in order to register a commit for an output in the blockchain, we have to prove no previous commit for that output in any of the previous blocks in the tree, back to block or summary block in which the output is registered. Only the client wallets of the parties to the transaction can produce a proof that a commit is valid if no previous commit, but only a peer can prove no previous commit. Once all the necessary commits have been registered on the reliable broadcast channel, only the client wallets of the parties to the transaction can produce a proof for each of the outputs from that transaction that the transaction is valid. They do not need to publish on the reliable broadcast channel of what transaction that was, and what the inputs to that transaction were.

So we end up with the blockchain only carrying order log(h) blocks where h is the block height, and all these blocks are likely to be of roughly comparable sizes to a single base level block. So, a blockchain with as many transactions as bitcoin, that has been running as long as bitcoin, will only occupy a few dozen megabytes of disk storage, rather than near a terabyte. Bitcoin height is currently near a hundred thousand, at which height we will be keeping about fifty blocks around, instead of a hundred thousand blocks around.

And when it gets so big that ordinary people cannot handle the bandwidth and storage, recursive snarks allow sharding the blockchain. You cannot shard the bitcoin blockchain, because a shard might lie, so every peer has to evaluate every transaction of every shard. But with recursive snarks, a shard can prove it is not lying.

115 Responses to “How to apply recursive snarks for a fully scalable, fully private, currency”

  1. Lat says:

    I need encrypted msging over SMS text channel.
    Do not have WiFi or Cell Data, so must use SMS channel.
    Can use text size limit for discrete message. But more likely
    have to use text as carrier channel for larger crypted msgs or stream
    since size limit maybe too small for even kex or sig.
    Txt is free here.
    help.

    • jim says:

      Use gpg and ascii armor. If the text block is too large, slice it into fragments and the recipient has to paste them together.

  2. Fidelis says:

    Jim, I would like to discuss further your ideas regarding a replacement consensus mechanism that overcomes the PoW centralization gradient. You outlined briefly something related to the filecoin consensus, and called it ‘Proof of Uptime’, with the goal that eventually all honest participants would converge on the merkle vertex with the most other honest participants. I am having trouble imagining how this overcomes sibil attacks, and I think the primary reason I am confused is a lack of detail. Do you have material available to share? I have read through all the docs I can find on your page, and find little additional information regarding this.

    • jim says:

      I have failed to write this up, or rather I have written it up, but I am not at all happy with the write up, and feel it unfit to be broadly read.

      Filecoin’s “proof of spacetime” from time to time gives every participant a test, and each participant creates a zk-snark that proves how it did on the the test, proves that it is carrying its weight. The test is structured in such a way that a thousand sybils running on one machine can each only carry one thousandth the weight.

      The test shows that each machine has the data it claims to have, and has reasonable bandwidth access to that data – a thousand sybils on one machine will each have one thousandth the disk access speed, and one thousandth the cpu processing power. But testing for connectivity is a harder problem, for the sybils will have near infinite connectivity to each other, while each sybil’s connectivity to the rest of the network will only be one thousandth. Testing for connectivity is a graph problem, graph problems are hard, and I don’t think Filecoin has solved that problem. I have not. Filecoin provides incentives for connectivity, which does not address the problem of incentives for gaming the consensus and generating a fake consensus. But proof of spacetime arguably suffices to prevent people from gaming the consensus – plus Filecoin is considerably more centralised than they admit to, thus attempts to game the consensus will run into organised and cohesive human action. But this just means the consensus is in a sense already gamed, or is potentially already gamed.

      One way out of this is proof of share, plus an incomplete, imperfect, and far from bulletproof proof of spacetime (disk access and cpu bandwidth) and an even more grossly imperfect and gameable proof of connectivity. You have a crypto currency, that works like shares in a startup. Peers have a weight in the consensus, a likelihood of their view of the past becoming the consensus view, that is proportional to the amount of the crypto currency their client wallets possessed at a certain block height, ⌊(h−1000)/4096⌋∗4096, where h is the current block height, provided they maintain adequate data, disk access, and connectivity. The trouble with this is that it reveals what machines know where the whales are, and those machines could be raided, and then the whales raided, so we have to have a mechanism that can hide the ips of whales delegating weight in the consensus to peers from the peers exercising weight in the consensus. And in fact I intend to do that mechanism before any crypto currency, because bitmessage is abandonware and needs to be replaced.

      Plus the peers consense over time on a signature that represents human board, which nominates another signature that represent a human ceo, thus instead of a secret informal centralisation with the capability to do unknown and possibly illegitimate things (hello Ethereum), you have a known formal centralisation with the capability to do known and legitimate things.

    • jim says:

      Prodded by your request, I have rewritten my proof of share mechanism, and added a consensus method that takes care of the problems Filecoin’s proof of spacetime takes care of in a very different way.

      https://reaction.la/security/design/proof_of_share.html

      • JacketMan says:

        Are the docs that describe the meta and techa of this coin available on a github?
        Also note that link such as above may be missing from a parent page on this coin.

        • jim says:

          I am working on it, and it is not ready for prime time.

          It is not going to go on Github, at least not as the primary and authoritative repository, because Github is enemy owned. I intend to bring up an instance of Gitea, and put the primary and authoritative repo there. And have reached the point where I should do that, but not yet the point where it would be good to solicit random collaborators. I have large pile of design, and a grossly incomplete skeleton of code. When the skeleton has most of the major bones in place, then open source style open entry collaboration is likely to be more fruitful and profitable.

      • Fidelis says:

        I have read this a few times over now, thank you.

        How familiar are you with Polkadot? They, at least specifically Gavin, seem and seemed to grasp the hostility of the “regulators”, regularly speak to the need to be un-regulatable, and built in governance in a way similar to your description, yet lacking a CEO signer as far as I can tell. It looks like they are more and more moving the “pay the devs” functionality to a bounty like system paid by the elected board signers. They also have a human name system, and are working on a mixnet system for IP hiding. They don’t have anything like your described private messaging system, as far as I can tell, however. The biggest tragedy I see is they originally had what looked to be a vision of coordinating soverign peer ledgers with the simplest most robust central protocol, but have moved more and more into simply being a monolithic blob and made it harder to hook in your own protocol.They also are a bit ossified into the design from ~2016 and don’t utilize much in the way of blockdags, lightning, let alone ZK tooling.

        Lastly, and most importantly, I don’t like where all their peers are hosted: https://telemetry.polkadot.io/#map/

        A few things I would like your input on, if you don’t mind:

        – You often describe a “lightning done right”, what exactly does this look like? Is there a dense source of knowledge compiled somewhere, or is this just from observation of the evolution of the current LN?

        – How could you solve the problem where servers end up far too concentrated in large enemy controlled server farms? This is something that deeply troubles me with just about every existing blockhain — with the possible exception of XMR which has its own issues — the actual infrastructure is not robust to physical capture. I feel you need to somehow incentivize peers to not simply rent a machine from AWS, but I don’t have any good ideas in practice.

        – Who is actually using tools like bitmessage for commerce? I am, shamefully, completely detached from that world. Is it just regular darknet stuff? Smurfing CC numbers, selling big bags of xanax and all that? You mentioned Russians using BTC and friends to trade goods, could you drop a few breadcrumbs so I can better inform myself on this? It’s quite opaque to me.

        – Related to the above, I can see a nice use case for a nice and private chain with highly reliable messaging and reputation as being a much better bridge between the fiat and crypto world through facilitating exchanges through the irregular digital windows like paypal, gpay, giftcards, etc. How else can we provide an escape hatch for those fleeing the fiat system, and is this a reasonable objective to begin with?

        • jim says:

          I am very unhappy with Polkadot. They seem captured to me.

          To achieve their ambition, they need atomic transactions with bitcoin lightning, which is straightforwardly doable. And they spent a great deal of time, money, and effort, to accomplish convertibility with bitcoin, and failed. And it appears to me that the reason for their failure was that they wanted a solution more amenable to financialization and centralization, a solution inevitably cumbersome and overcomplicated, rather than implementing it in the glaringly obvious manner.

          If you set up lightning on the polkadot chain, it is then straightforward to set up atomic exchange between bitcoin lightning and polkadot lightning. And instead they pursued an overly complicated and cumbersome solution more amenable to centralization and financialization.

          If they had done it in the obvious and straightforward way, it would have very substantially improved the convertibility and liquidity of polkadot, and thus the value, since these days lightning is more spendable than any other crypto currency. But they did not want to.

          Lightning done right is Anonymous Multi-Hop Locks for Blockchain Scalability and Interoperability

          Lightning says they are kind of sort of moving towards this, and perhaps they are. I have not looked at the code.

          You can lease a host over bitmessage. But few hosting services provide this capability, and bitmessage is abandonware that is dying of bitrot. Not aware of bags of Xanax, but that is an obvious application – and indeed it is well suited and secure for such an application – but we need a reputation system running over bitmessage to adequately enable gun running and so on and so forth.

          Albeit the biggest money by far would be facilitating Chinese evasion of capital controls. Bags of Xanax are small change.

          > How could you solve the problem where servers end up far too concentrated in large enemy controlled server farms?

          Big and immobile miners are a far more serious and immediate problem.

          But the solution to the concentrated server problem problem is to put all the power and the valuable information in the client wallet, and deny the systems that will inevitably wind up running in large enemy controlled server centers any autonomy and power.

          I plan to have delegated keys: The identity of a server will be key signed by a key signed by a key signed by client wallet, and very likely the root identity will be in a cold wallet, and everything that might be vulnerable to enemy action in highly concentrated enemy controlled server farms will not matter much.

          • Crypto Fools Fear Authority says:

            [*all your posts are held pending you passing the shill test.*]

          • Fidelis says:

            Albeit the biggest money by far would be facilitating Chinese evasion of capital controls

            Personally, I would love to facilitate my own evasion of capital controls. What exactly are the ingredients you see as lacking in the current infrastructure, that prevent it from realizing this goal?

            I am very unhappy with Polkadot. They seem captured to me.

            To myself as well. I thought it overall prudent to share, as having done many things correctly, they still failed to evade destructive entryism.

            put all the power and the valuable information in the client wallet, and deny the systems that will inevitably wind up running in large enemy controlled server centers any autonomy and power

            If the consensus is directed by actions of the peers, even if the peers are ‘undelegated’ after the fact, couldn’t you cause major problems? Though I suppose clients eventually route themselves to uncaptured peers, eclipse and long range attacks could wreak quite the havok in the meantime. Thought I am short on ideas, I nonetheless cannot help but feel we need a way to incentivize such behavior before it becomes a problem, not after

            • jim says:

              Each client keeps his own copy of that small part of the blockchain that points to his transactions. If history gets rewritten, stuff will just not work. The danger is that a capture operation accepts the previous history, and starts to write events after that with those they deem undesirable excluded.

              But if the transactions are not in the public broadcast channel, merely the hashes of those transactions (whose preimage is the private blochains of client wallets and interacting transaction client wallets) it is going to be hard for them to identify undesirables) At scale, every person and every group has their own blockchain, linked into the one universal chain by hashes in the public broadcast channel. Otherwise it just will not scale. Though at small scale, we will probably at first have something less clever, because I worry about people losing their state, which is a big problem with lightning.

              • Fidelis says:

                With eclipse and long range attacks, it’s not rewriting but double spending that becomes an issue. Its attacking the network by making hostile and incompatible forks that are damn hard if not impossible to distinguish from honest consensus without human knowledge. I don’t see them as long term deadly, but after a massive successful attack it would take quite a while for the network to resolve the branches, and even more time for people to then trust the network again.

                I worry more that requiring clients to keep state is simply incompatible with the average user of these things. It’s hard enough for people to deal with seed phrases. People capable of dealing with backups and even mild admin are not the norm.

                I could see it working if there was a way for clients to agree to share state amongst each other. Possibly just the bilateral transactions/messages, possibly an erasure coding scheme elected into among several clients. It cannot be so easy to lose your money to a faulty hard drive, or anything like that.

                • jim says:

                  What I have in mind is that when the public broadcast channel is conveniently small, people keep their state on the public broadcast channel as with bitcoin, but encrypted to their secret keys, and old state that will not lose your money by being lost being discarded after a while. That does not scale, but recursive snarks make sharding possible, because each peer does not have to prove that every transaction that ever there was is valid — which is to say, as the public broadcast channel gets bigger, and the cost of storing stuff on it rises, as it is rising now with bitcoin (the transaction fee crisis) people start sharing encrypted state among each other, (sharing in a shard) and cease to share it on the entire public broadcast channel, which just stores the hashes of the roots of what smaller groups are sharing, the hashes of the roots of their shards.

                  The public broadcast channel is what everyone shares, which in bitcoin is the entire blockchain, because every transaction has to be validated by everyone. When it starts to get large, we break that up into shards.

                  We use a dht to map public keys to shards – normally each client knows its shard, and each peer knows the shards of its clients, and does not have to look it up on the dht, but if a client who has lost his state logs in to a peer, the peer looks up the shard on the dht, then puts the peer wallet in contact with members of its shard so that it can recover its state.

                  Initially when small, not going to have shards, but the architecture has to be compatible with future sharding, which means that a dht of public keys will likely need to be integral from the beginning.

                • Fidelis says:

                  I have been giving the problem of big hardware a lot of thought, and I find myself more convinced, perhaps mistakenly perhaps not, there must be a potential network architecture that can facilitate a network of a vast number of lightweight low bandwidth home servers instead of a scarily centralized network of big data center machines.

                  The solution lies in the way you shard the network. The consensus nodes, the most critical, are merely ordering hashes in a dag, this is not heavy weight. Looking at the architecture implied by narwhal style mempools/databases with linear scale out from workers, and the theory behind sampling node leaders in byzantine networks, I believe it is very possible to have a vast pool of workers with round-elected leaders for consensus. The problem with very large PoS networks is collecting and distributing many many consensus messages and signatures. If you sample nodes for consensus leadership instead, can have a much larger pool of nodes without that tradeoff, instead trading for some more complexity.

                  The detail I am not as convinced on, is the addition of zk proofs into the consensus loop. Zk proofs are very heavy and expensive, especially the ones filecoin runs. They can be less heavy and expensive if you are proving simple things, such as a hash preimage or two and a signature, but the kind of proofs you need for proof of storage and bandwidth and suchlike are heavy. I am convinced you need the addition of entropy in the consensus loop to make it unreasonably hard to simulate fake histories, but not convinced proof of storage and bandwidth can facilitate a decentralized network in the current state of hardware and proofs.

                  So, painfully light on details description of a transaction in this theoretical network. Client A makes a zk proof of transaction X, sends it to worker Z and client B. This proof points to the most recent merkle vertex found from the consensus network all the way at the top. Worker Z batches many such proofs, zk recursion not necessarily needed, as client B holds a proof of correctness and the new utxos, creates a hash of this batch, sends it to validator Y. Validator Y hashes these hashes into a dag vertex, and the leader block points to all the dags from the previous consensus round.

                  In this way, clients validate the state they are concerned about, workers and validators only provide a total order history. It doesnt matter if bad hashes are included in this total ledger, because you cannot make a proof with bad data. So the workers and validators can be blind and unburdened. The reliable broadcast problem is reduced to simple hash-pointers. Of course you can make things more complex and have workers store state, but for payments (and even message chains if you collapse them into a hash that goes with the zk proof) this should be enough. It relies on clients storing the important data, but you can envision a sub-worker handling such things for many clients as a trusted service provider without breaking the overall security of the network. Just as in nostr most just trust the relayers, you can pay some sub-workers to hold your data through streamed payments or if you are savvy run your own.

                  Now I understand this is not a full spec and is possibly hiding many gremlins, but do you see any clear and obvious flaws from this vantage point?

                • jim says:

                  Yes, sound design. And I have been thinking over this issue a lot.

                  But while this design makes a truly decentralised network possible, the problem is that due to laziness and economies of scale, a truly decentralised network is not necessarily going to result. Most people seem perfectly happy to hand all their emails over to Google Gmail, who sells the information to all sorts of people who do not have your best interests at heart. And I see no end of businesses using Google Analytics, who sells their customer list to their competitors. There simply is never any good reason to put Google Analytics on your website. It is stealing data from your business and from your customers, and selling it to their enemies and competitors. It is just that Google makes it easier to install Google Analytics, while an in house solution is slightly more work.

                • Fidelis says:

                  You point to a hard problem that I honestly believe there is no good solution for. Natural slaves will act as such. With email, the solution is independent namespaces. With analytics, a market for software. With lazy humans, a market for slave owners. Or rather, a client relation network.

                  The problem is not necessarily market access, I mean this in the broadest sense of market. Anyone can stumble into your blog. That is enough. We don’t need a diluted lowest common denominator network. We need a network that can avoid censorship and capture, and the naturally skilled will migrate over time. They will migrate at first because there is no better option, and later because there will be advantages to networking with the talent found within.

                  So the work to do now is to build that network that can survive the roughest of attacks. As other networks get pwned by regulators and bad planning, we will sit clean and open and scalable, waiting with lifeboats. Clients will always be clients, but if the network is amenable to a vast network of client managers, things will work out fine. The problem with BTC is the miners have a centralization gradient, it makes the most sense on a physical level to cluster equipment in the places with the cheapest energy. The problem with lightning is that the capital and time/attention costs of channel management, plus the natural gradient inherent in the routing system, leads to very large channel operators that can be captured. I don’t see the custodial client managers in LN to be a long term issue in the same way, as if channels are not so centralized you would quickly end up with many many competing managers eager for clients. Sure they might do bad things with client data, but if you are concerned you can in-house that function– so long as the network itself is capable of supporting those with basic technical aptitude and standard server and internet access. Lightning is not, or rather will not be as we reach that scaling horizon, and even today is expensive and annoying to run.

                  So, somewhat contrary to my earlier post, I now believe it is not entirely terrible to have fat clients responsible for maintaining data. There’s ways of mitigating the risks of data loss, shared erasure codes and suchlike, and someone will always be there to sell to the helpless in exchange for their pound of data and some fees. Hard to care too much about the helpless. More concerned about the network avoiding centralization gradients, and that means putting all the gravity at the farthest edges possible. We cannot require fat servers with fiber cables the size of your wrist and the latest A10s to run big proofs in order to secure the network. Too big a capital cost and too easy to just rent. We need something where a guy can buy a cheap used server, fiddle with his router ports, run a binary, and be eligible to help secure and operate the network as a peer. I believe this is achievable and scalable enough to handle the world’s transaction volume.

        • jim says:

          What I think is going wrong with Polkadot is that the sincere freedom loving left anarchists who are all over Polkadot lack the immune system to resist state sponsored state leftism, and state leftists want to implement a pan-opticon run by big finance.

          The expensive and ever running project to provide an interface to Bitcoin failed because the only effective and straightforward way to do it would have promoted crypto anarchy.

          • Fidelis says:

            Indeed, the best proposed system for a real crypto swap market I’ve seen is *exactly the same structure* as your written layout for a social media that can resist spammers

            The orders broadcasted are stored by the nodes in a decentralized manner using a distributed hash table (DHT) [1]. Every full node can activate the DHT-DEX functionality: nodes are free to sync the full DHT, prune it, start partial sync only when they are online (starting from the most recent orders), or not sync at all. Once activated, the node begins syncing the Distributed Hash Table of orders from the peers.

            Not all orders that reach the peer are registered on the hash table; instead, each node stores only those orders that are filtered based on their interest and will pass on to the network only what is stored, just like it happens on BitTorrent or other similar peer-to-peer systems. A bigger DHT grants more opportunities to find a successful match, but on the other hand, it takes more time and resources to be synched and stored.

            It means that all nodes will never share a single equal DHT, and likely there will not be nodes who know or store the entire book history since the complete set of orders is stored only collectively in many fragmented tables in possession of different node owners.

            This is from mintlayer (https://docs.mintlayer.org/whitepaper/5-decentralized-exchange-dex). There’s a lot I don’t necessarily like about their chosen architecture, but this is one aspect that is perfectly matched to how crypto swaps and communication should actually be done. I don’t see this pattern explicated anywhere else despite its obvious strengths. Even something like CivKit is hopelessly centralized in comparison.

        • jim says:

          > The biggest tragedy I see is they originally had what looked to be a vision of coordinating soverign peer ledgers with the simplest most robust central protocol, but have moved more and more into simply being a monolithic blob and made it harder to hook in your own protocol.

          Deep state enemy action. That is what killed Polkadot’s convertibility with Bitcoin. It was and is full of sincere well meaning left anarchists, but the money and the power was always in deep state hands.

  3. Dev Now bc Bitcoin PsyOp Fail says:

    Hear me out on this… it’s not really a prediction, because there are a handful of people out there who are speaking frankly on this in public, at least for so long as they can withstand the attack by the Legacy Anti-Freedom 1984 Dark Actors who employ the Laser Maxi Army via an intermediate layer of Umbrella Men that seed their thought memes into the public.

    BTC blocks have been totally full for months to years relatively speaking, and have been 100% full lately, everyone concedes this is now permanently 100% full. Fees are now going to rise toward prohibitive levels FOREVER, there is no escape.

    Lightning is NOT a solution because LN does not meet human’s natural p2p transaction semantics encoded in human DNA. And LN does not give access to liquidity options like L1 does. And since everyone on LN must roll up to L1 eventually, you WILL NOT be able to due to L1 fees. And LN will jam up due to inability to settle, and you won’t be able to execute pure custody on LN either. And privacy gets priced out too. And LN towers will be corrupt. etc. Plenty of videos on all LN’s problems.
    Even Jim posted good notes that cover more problems of BTC / LN.

    Everyone but the big Govts Banks Corps and Whales is going to be priced out of self-custodial transacting in the underlying non-paper asset… that means YOU.

    If you want to use custody “solutions” and paper coins, that’s fine your choice, but you absolutely MUST realize that at that point you’ve given up all SOVEREIGNTY and PERMANENTLY LOST THE GAME to the enemy.

    The main problem with BTC/LN is 1) txrate and 2) fees, bringing in 3) settlement and 4) custody… these things are existential unsolved threats of fact right now today, and every HONEST analyst will tell you that. Everyone else is scared shitless of this fact and is thus shilling hopium while they try to extract and min-max gamble on a future peak exit route to a better product which doesn’t really exist yet.

    In fact, many old whales have already cashed out, or in this cycle will either do so, or will permanently encumber their stack in exchange for income or liquidity, and walk away as BTC jams up and burns.

    YES do NOT get me wrong, you’re going to make a fuckton of money on this upcycle, but after the peak, BTC is done due to realization of the above. And when the peak hits it’s over for you if you can’t find liquidity at least back to fiat, if not into a better product. It will be brutal… DO NOT fuck around trying to time the peak, GET YOUR IN’S OUT EARLY.

    Don’t get me wrong, I like OG Bitcoin, but OG BTC has long ago been taken over by those big players who give ABSOLUTELY ZERO SHITS about your FREEDOM to CUSTODY and TRANSACT, else they would show you that, but they can’t, because BTC can’t, so they hide these facts.

    Bitcoin MUST and WILL be forced to raise the blocksize and cut the blocktime.
    But it is these major players who will do that, and only up to the point that
    they and not you can use it, because its so untransactable now that even they
    can’t use it as a tool to fuck each other, or you, over with it if they don’t raise those.

    But in longer term reality, Bitcoin needs to be outcompeted by, as someone said, a better “P2P [Private] Electronic Cash”.

    Please start researching what projects are out there, join with them, or create new projects.
    Maybe it will look similar to Bitcoin, maybe it will be much different, but it must work as a usable “100-year” coin.

    Because, in my opinion, as it stands in its current form today, Bitcoin is dead.

    Again, I’m open, to any Bitcoiner who can show us, and to competing coins,
    but the gaslighting and shilling of BTC / LN has reached extreme absurdity
    when taken up against its problems.

    Note to Jim: If your ZK thing is perpetual-scale, put politics on hold and
    get it fleshed out and out there, becase the world needs papers to
    choose from and develop and run release projects and adoption around.

    Note to Everyone: Cryptocurrency is a MUCH bigger game than you think,
    Legacy Powers are PsyOp’ing and seeding narratives to keep BTC
    going as a trap. Please wake up. You absolutely must create and use
    alternative Cash coins. The fact that there are almost zero such sound
    alts in the market, let alone competitors being used, should tell you something….
    it’s not that BTC is better, it’s that PSYOPs are being run against
    the free market that should by definition of free market should
    always have a handful of competitors.

    • Also Filtering says:

      Also, both BTC and LN nodes have been caught filtering and censoring tx, its getting worse, and will be a real problem when the environment of 1~2 above forces even more centralization of mining, routing, and custody.

      Filtering is defeated by coins that are native full-time in-protocol privacy coins… Zcash and Monero (as examples, not as a privacy or scalability endorsement)… where there is either no public component, or one that emits via a privacy core. ZEC/XMR aren’t perpetual-scale.

      Mix coins such as XEC/BCH only work if the fees at perpetual-scale are low enough. And those two seem to use a bannable 3rd party service, not an in-built in-protocol mix.

    • jim says:

      All you are saying is that crypto currency has hit the long predicted scaling limit.

      But the cavalry has arrived. We have the fix.

      • Crypto Future says:

        Jim, if you feel you have the fix, or a fix, I cannot encourage you enough to shift your time from politics over to drafting and releasing your whitepaper and even forming a group and refcode. As an OG, you know that nothing else matters but crypto… money… back in the hands and tx freedom of the people. If you need help, seek it from crypto twitter, as I am of limited help, but will assist with any good project that comes along.

        My gut is that BTC / LN isn’t a good feel, that we’ve not yet discovered or assembled anything near the best solution that will theoretically be possible, that we’ve wasted 15 years of getting closer to that by “settling” on BTC. Never settle till the laws of physics defeat you, and then never presume the physics can’t be extended or refuted in a different direction.

        I think the pain point will come sooner, between $125k-$250k.
        It is scary how strike and square are getting seed money from fools, what blackrock is doing, the history behind blockstream and CIA, where CBDC is going with BTC, exchanges miners and routes as chokes, etc.
        I think all this comes courtesy a non-perpetual-scale coin like BTC.

        Do NOT settle for “backed by” BTC, or by whatever coin, this is early science, we’ve no reason to settle yet.

        If cryptos can do better, then now is the time to do the best we can, again, now, 15 years later.
        And again in another 15-20 years if we have to, no problem.

        I “sense” the currently felt consensus general theory scaling limit, but I am optimist on a range of alternatives or optimizations or designs that have not been beneficially modeled or discovered yet. the science is still pretty early on this point. Satoshi was the first model, but no proof exists that Satoshi is the only model possible.

        I think the long game for privacy coins is valid and winning one… NO, people are NOT going to get wealthy instantly from them, but that’s not the goal, if humanity gets a perpetual-scale privacy coin, then it will win in the end.

        Capabilities… you don’t even need full time native privacy in protocol (ie XMR ZEC), IF the “cost” of crypto levels of mixing is trivial. But as early days optimist, I model check for native first. The people are sadly being priced out of weak levels BTC coinjoins right now today.

        Also, there is such thing as feeless mining altruism volunteer, and mining-less coins… all options are open. Free minds create better novel solutions.

        Yes, shitcoins are easy to eliminate, I’m so sick of seeing them, so many foundations premines and other corrupt things, The world’s people just want sound cash money sovereignty on their phones, nothing more, nothing less. Fair Satoshi altruism wins, you will have plenty time to buy or mine in early days. I posit there are only far less than 10 potential BTC replacement projects out there.

        I hope yours becomes one of them soon.

        • ZK Podcast says:

          Zero Knowledge Podcast
          https://www.youtube.com/channel/UCYWsYz5cKw4wZ9Mpe4kuM_g

          For those that like to investigate ZK as one integration
          option, this is the only generic (mostly non coin specific)
          ZK channel I could find for people to browse so far.

        • jim says:

          > that we’ve wasted 15 years of getting closer to that by “settling” on BTC

          I don’t think we settled for BTC. There has been ceaseless effort and thought at finding a solution to the problems that were immediately identified when Satoshi proposed Bitcoin. It is just that these are very hard problems and we have not yet had much success solving them.

          A whole lot of very smart people have been working tirelessly in the shadows, while a whole lot of dumb scammers looking for dumber marks have been working loudly in the limelight.

          You are complaining that the dumb scammers looking for dumber marks while working loudly in the limelight are being ignored. No, they are not being ignored enough.

      • Zero Knowledge Podcast says:

        Zero Knowledge Podcast
        https://www.youtube.com/channel/UCYWsYz5cKw4wZ9Mpe4kuM_g

        For those that like to investigate ZK as one integration
        option, this is the only generic (mostly non coin specific)
        ZK channel I could find for people to browse so far.

    • jim says:

      There is no alternative to BTC, except Monero.

      And Monero, has, for the sake of privacy, sacrificed certain important capabilities.

      The problems you correctly say will afflict BTC, will become intolerable, and will adversely affect BTC to approximately the extent that you predict, around the time that one bitcoin passes one million dollars, and everything else except Monero drops below a dollar.

      Everything else is a shit coin or a scamcoin, and these days, always a scamcoin.

  4. BTC Lightning Sucks Move On says:

    So thanks to this blog I heard more apparent truth about some Lightning things.

    So I went and looked it up, what it can do.

    It generally follows BTC’s nonstop decentralized unstoppable processing ethos, which is good.

    It’s fast, which is good.

    But not completely reliable pathing and tx (yet, as they say, but it looks like a protocol problem, so theres no fix), which gives you a terrible non-finality feeling of flakey money in limbo, which sucks.

    Your peer must also be using LN, so that sucks.

    Any small payment gets washed out by [*deleted for idiocy*]

    • jim says:

      You started out with an accurate account of lightning’s defects, but the rest of your argument presupposed that neither participant to the transaction keep any money in lightning, which is like critiques of BTC that presuppose that neither participant keeps any money in BTC.

      Yes, doing lightning transactions is difficult, expensive, and inconvenient if neither party keeps any money in lightning. And similarly, it is not very useful to transact with a merchant in BTC unless you and the merchant are both hodlers.

      If both parties have a lightning wallet, it is cheap, easy, and convenient and fast. Albeit a having a non custodial lightning wallet is difficult, and if you do not know what you are doing, dangerous and dangerously complicated. The latter is the valid critique of lightning, and had you addressed its real defects, I would have allowed it your comment through.

      But I silenced you because you both for making foolish arguments, and for not making the considerably stronger arguments against lightning that I have made and you have failed to read.

      Yes, BTC mainchain is dying under the weight of its success, with main chain transactions becoming intolerably slow and expensive due to the seven transactions per second limit.

      And yes, unless both parties have open lightning channels with money in them, lightning does not work, and genuinely noncustodial lightning wallets are an immense pain in the ass, and too dangerous and hard for normies.

      But if both parties hodl, and both parties have lightning wallets and keep money in them, it is great.

      • Stupid BTC Shills says:

        What kind of stupid is this…

        “not very useful to transact with a merchant in BTC unless you and the merchant are both hodlers.”

        UTTER BULLSHIT.

        Both need BTC L1 wallets.
        But ONLY I (the spedner) need to hodl a utxo, to spend to his empty (aka: non-hodling) wallet address. He is NOT a hodler till I send him coin. DUH.

        “BTC mainchain is dying … becoming intolerably slow and expensive due to the seven transactions per second limit.”

        Ignorance.
        No it’s not “becoming slow”, it’s always and forever still just 10 minutes, and if you didn’t ante up to get your tx in the first 10, your odds on any later 10 are still roughly zero nowdays.
        TPS does not affect “slow”, it only jacks up fees to unusable levels for everyone but bankers.
        Tick tock same clock.

        Eventually, yes, everyone but bankers will be washed out of L1 by fees and trapped in L2, forever, nobody will own real settled L1 money anymore. Unsettled L2 state will bloat and fail all to hell. This also means all these millions of stuck L2 plebs are getting washed out of some liquidity and other options too that will only be available to those who can tx on high-fee L1.

        “convenient”

        No, not if user has to stay awak another 8 hours to send his ppl across the earth money they must be online to click their wallets to do the LN pay-sigs to update the state.
        And will be hell inconvenient when their L2 citadel peers keep dying randomly taking state hostage, or exposing their data.

        The OP should repost his censored comment in full so we can see what other legit flaws he noted.
        You shied away from and did not address his points.
        Just like politicians ignore and censor when their whack ideologies get busted.

        “having a non custodial lightning wallet is difficult, and if you do not know what you are doing, dangerous and dangerously complicated. The latter is the valid critique of lightning,”

        So that’s the only thing wrong with LN you can think of? Wow, lol.

        “had you addressed its real defects”

        I suspect he did cover many, including probably that one. Let us see what he said.

        “that I have made”

        Nobody has to parrot you in every post… what a dull blog that would be.

        • jim says:

          It is completely obvious that you lack familiarity with the bitcoin economy, have never used bitcoin as money, and if you continue posting ignorant crap out about subjects you know nothing about, I am going to silently delete your stuff.

          > > “not very useful to transact with a merchant in BTC unless you and the merchant are both hodlers.”

          > UTTER BULLSHIT.

          > Both need BTC L1 wallets.
          > But ONLY I (the spedner) need to hodl a utxo,

          If the merchant does not have bitcoin, it is because he does not want and does not know how to use bitcoin, so immediately converts all bitcoin he receives into cash. Which is an immense pain in the ass for him, so he outsources that job to a payment service provider, which is an immense pain in the ass for the purchaser, and is still a pain in the ass for the merchant.

          For payments to be easy, both parties have to be using bitcoin as money, in which case both parties will have bitcoin, and the bitcoin the merchant receives goes into his wallet with all the other bitcoins he has already received and stays there until he needs to spend it on something, which makes him a hodler. Payment services are pain in the ass, and if a merchant is using a payment service to receive crypto, and you want to buy something with crypto, you are better off finding a different merchant – one who thinks that your money is money and acts accordingly

          And if he thinks your money is money and acts accordingly, past payments by previous customers are going to be in his wallet. He is not going to be sweeping bitcoin into fiat, he is going to be sweeping fiat into bitcoin.

          If he is sweeping bitcoin into fiat, you are going to run into a payment service like Bitpay, who is always going to screw up both the merchant and the customer. The big advantage of bitcoin is that it cuts out these pain-in-the-ass middlemen, and thus removes a point of failure. Removing the middleman points of failure was Satoshi’s big reason for bitcoin. Credit card companies are disaster, dealing with them is a pain for the merchant though it is easy for the customer. Payment services like Bitpay are pain in the ass for both merchant and customer. Things go wrong for one, or the other, or both, and they go wrong a lot. As they do with credit card payments.

          If the merchant is not a hodler, then crypto currency has no advantage over fiat, and substantial disadvantages. Yes, it can be done in principle, but no one wants to do it in practice. It has all the disadvantages of fiat, and additional disadvantages.

          > TPS does not affect “slow”, it only jacks up fees to unusable levels for everyone but bankers.
          Tick tock same clock.

          If you don’t want to pay the price that only bankers want to pay, you can pay a vastly lower price, and usually your transaction will go through. Eventually. And then it is slow. The great majority of people pay a price that results in transactions likely to be delayed by hours or days. I generally take a look at the mempool, and set a fee that will likely result in my transaction going through in eight hours or so. Which is a major pain in the ass that lightning cures. Which you would know if you had ever used bitcoin as it was designed to be used and as lots of people are now using it.

          > Eventually, yes, everyone but bankers will be washed out of L1 by fees and trapped in L2, forever, nobody will own real settled L1 money anymore

          This is the scaling problem. I have a solution for the scaling problem now, and so do some other people who may well be well ahead of me.

          L2 does not solve the scaling problem, but it postpones it a for a long time. An enormous number of lightning transactions are going through very fast, and soon vastly more will be going through very fast. But the scaling problem at level one is still biting and is going to bite harder.

          > user has to stay awake another 8 hours to send his ppl across the earth money they must be online to click their wallets to do the LN pay-sigs to update the state.

          That is not how any of my lightning wallets works. I have to click to send money, but a computer located in a secure place that I rarely visit in person receives money all by itself, and I eventually get around to checking on it over the network to see if it has received the money.

          As for your other criticisms of lightning and bitcoin, you are an ignorant fount of misinformation. You are spitting out a script written by fools for fools.

  5. Klamm says:

    If people want to get their new scalable privacy coins going, they better do so fairly soon, because a number of candidate privacy coins are in development now. And as was Bitcoin, network effects of the first few nextgen entrants will be difficult to overcome by later players.

  6. Mister Grumpus says:

    Our fellow traveller Zman isn’t a computer scientist, but a few clips from his latest really crystallize why a many-to-many crypto communication system — I presume relying on ZKSnarks in some fashion — is so desperately needed now:

    “Send a middle-class man to prison and he will be victimized by the system until he gets smart. He then goes to the extreme, assuming that he can trust no one. In time, he figures out that he can trust certain people, but he can never trust the system. Low trust societies have the same sort of trust relationships that you will see in a high security prison.”

    “All the highly choregraphed media in the world is no match for the word of that guy who has proven to be on the level.”

    Anonymity makes it possible to be That Guy and get away with it, but without having to be a daredevil computer genius like Jim here, and the decentralization of censorship makes it possible for others to discover him.

    The harvest is so great but the laborers are so few.

  7. VPNGates needs nodes help in various Western countries
    and places that aren’t Asian nodes.
    Buy a cheap shell account, or however many cheap ones
    you like, and run some nodes for a few years.
    Gives a lot of people alternative access that is different
    from banned-Tor and well-known commercial VPNs.
    Useful for exchanges, nodes, comms, debugging, etc.

    • jim says:

      I have researched VPNGate, and would never go near it. It is a honeypot, enemy controlled, backdoored.

      It started with the best of good intentions, but they allowed hostile enemy entryists in. Every crypto project is besieged by enemy entryists.

      • jim says:

        In the reply, which I suppressed, it became completely obvious that the author of that comment promotiong VPNGate is a government shill, not a deluded volunteer.

        Which tells us something very interesting. The government, by promoting a VPN service that it controls root and branch and which reports every interaction to our enemies, reveals that not all VPN services are similarly powned.

        Just as the existence of the Troofers reveals that there is something very smelly about 9/11, but what smells is not holographic airliners nor magic thermite, and certainly not dancing Jews, but rather strangely pally relationships between government and arab terrorists, this shilling effort reveals that the vpn situation is not as bad as some people feared.

        That our enemies are promoting Vpngate to us implies that most of us are using vpns better than Vpngate. And that Vpngate glows in the dark, and the shill promoting it glows in the dark, tells us our enemies are clumsy, incompetent, and stupid.

        Wireguard is secure against state level actors, unless they own your vpn host, which they might. Therefore, if your vpn offers wireguard, that does not necessarily mean they are not powned, but if they do not offer wireguard, definitely powned.

    • MrPatton on VPNGate says:

      VPNGate is cool because it [*deleted*]

      • jim says:

        VPNGate is a honeypot, and everyone promoting it is working for the deep state.

        To prove you are not employed by our enemies take the shill test against shills under deep state supervision.

        VPNGate was originally started by a bunch of genuine volunteer enthusiasts, but the entryists moved in, and every single volunteer enthusiast, every last one, eventually dropped out, with the result it is now just another branch of the FBI wearing their CI hats.

        NordVPN is also a honeypot – they rewrote wireguard, the only secure vpn software, and make you use their proprietary closed source wireguard. Their excuse for rewriting is that they rewrote it to comply with their no logs policy, but wireguard by default generates no logs. And if you switch on logs, it is difficult and complicated. Wireguard does not make it easy. And in the event you manage to get wireguard logging working, it gives you debugging logs, which are not very useful for spying on people, and which slow down the vpn horribly, making it impractical to keep logging permanently switched on. Wireguard logs are designed and intended to be turned on when something is going wrong, and you are trying to figure out what is going wrong, and then when you have fixed the issue, you turn them off again.

        If a vpn provides wireguard, and encourages people to use it, they are probably not logging, because logging wireguard clients is pain in the ass. Unless you create your own closed source version.

        All vpn software other than wireguard is insecure, so a vpn’s policy towards wireguard tells you what their policy is towards privacy. If they make it difficult for their clients to use wireguard, they want you to use insecure software, and they are finding that logging their wireguard clients is a pain in the ass. Wireguard logs are designed to enable you to find what is going wrong, not enable you to track what is going right for your clients. They can be used to track your clients, but that is not what the people who wrote the logging code had in mind.

        • Cloudswrest says:

          Using Wireguard yourself, it looks like you have to spring for your own cloud based Linux server.

          Such servers within the empire are probably pwned by GAE.

          Outside the empire, it’s been my experience that IP address arising from outside the empire often cause services like online banking, etc. to go ape shit when you try to log on.

        • skippy says:

          Something interesting about NordVPN is that it has some locations physically outside GAE, for example Hong Kong, which most providers do not.

          • jim says:

            You are a glowie, and only glowies push NordVPN.

            PrivateVPN has locations in Hong Kong and in Russia and Russian aligned countries, which are now extremely valuable as the Great Global American Empire firewall is cutting access to Russian websites in many countries. PrivateVPN promotes the real wireguard, with open source code, unlike NordVPN which forces you to use their closed source code which allegedly implements an improved version of wireguard, and PrivateVPN accepts bitcoin directly, unlike NordVPN which accepts them through an aggregator who is required to report every detail of every transaction to Global American Empire, because officially registered in the money changing business. It appears that PrivateVPN are not money changing, when they get bitcoin, they hodl.

            Does this mean that PrivateVPN is not collecting all your data and selling it to anyone who pays? I don’t know, but I do notice that glowies would like us to use NordVPN and VPNGate, which are readily identifiable as glowie operations, which would suggest that not all commercial vpns are entirely useless.

            You guys need to work on your glow. One of my commenters said he knew someone was glowie, but would not explain how he knew because this would give them pointers on how to avoid glowing so brightly. I have been giving you pointers on how to glow less brightly for as far back as I can remember, and you still glow.

            • Cloudswrest says:

              I downloaded and subscribed to PrivateVPN on my Windows machine. Seems to be working fine. I then downloaded and configured Wireguard via PrivateVPN. This also appears to be working fine EXCEPT … when I’m tunneling via Wireguard I loose access to my NAS drive on my LAN.

              • jim says:

                this is fixable, and lots of people have encountered this problem and fixed it, but fixing it is arcane.

                The problem is that the client on your computer attempts to access the NAS drive through the VPN So you have to twiddle with routing to enable software to see the local network, but not see the local internet gateway, and instead see the wireguard internet gateway.

                I wont tell you my fix, because it is even more arcane.

      • jim says:

        I don’t understand why you guys persist. Whenever I get a comment that glows I delete it and ask for the shill test. If the shill test is not forthcoming, I delete all subsequent comments with a snarky put down, and eventually go to silent deletion.

        You can pass the shill test by copying and pasting the answers, which I fairly regularly post. You can pass it by disagreeing with the answers in a way that makes it clear what the answers are that you are disagreeing with.

  8. Survey Crypto Teams says:

    Generally speaking, assessing the current state of the crypto space…

    How long on average in months should it take for a new serious L1 competitor [1] in the crypto space to develop a cryptocurrency protocol whitepaper, all the way through writing a fully implemented reference client, and getting it to beta running transactions on a testnet at a level of quality sufficient for launch?

    6, 12, 18, 24, 30, 36, or roughly how many?

    [1] Aiming to become global top 5 in long term actual usage, not a stable or shitcoin or centralized, more about money and privacy and such things, less about VM or smart contracts or features

    • Henrik says:

      Maybe around 24 at most? What do you guys think?

      What new research is needed for a competing L1?
      Or can they compete by just assembling current tech?

      For example…

      Bitcoin probably took much less than a year from “Aha moment”
      to launch, and BTC’s “Aha” just applied 100% pre-existing decades
      old simple primatives algo tool libraries cobbled into a new
      assembly design vision.

      Whereas ZK and PQC are still hot developing fields in mathmatical cathedrals.
      As are maybe some graph and node and communication theories,
      crypto transformations and constructions, etc. All still yielding new
      discoveries, optimizations, etc.

      So do you have to assemble it, or create it, or wait till someone creates stuff that you can then assemble?

      • jim says:

        Working on it. Going slowly.

        A whole lot of hot stuff is coming down the road, but the big important thing was the recursive snark implementation going open source on Github. Solves the scaling problem and the privacy problem. All the other new developments are not that important. Recursive snarks are important, because they make it possible to prove current transactions valid without having to keep all transactions around forever, and without having to share the transaction data with anyone other than the parties involved. You still have to register the hash of every transaction output, which is a bandwidth scaling limit, but recursive snarks also solve the side chaining problem, with sidechains working like correspondence banking.

        I want to also address the Certificate Authority problem – not much money in that, but a whole lot of concentrated power and an enormous privacy leak. Also helps solve the cold start problem, because it addresses a problem no other crypto currency addresses. If you have securely private money, some people are going to want the metadata, the conversation about the payment to be private.

      • Kelly says:

        Shitcoins take 1 month, they’re just renamed and reparam’d clones or tokens.

        A true L1 competitor might take a year or so to write the coin
        idea into a protocol paper and code a client to spec.

        One person usually not skilled to do both paper and code,
        so teams of two to four are common… paper, code, admin,
        social.

        No one but maths academics invent new crypto and computing
        primatives, coin people just look around for what they can
        already mashup to meet their coin design idea.

        • jim says:

          Bunch of libraries around to implement what is needed. Glueing them together, however, takes time, and the very latest ones (recursive snarks) are kind of raw, special purpose code that is not really as general as a library needs to be.

          What I am missing is a library for peers to find each other. I am not sure what to look for, or what work has been done in this area. I cannot seem to just plug it in like Sqlite, wxWidgets, or libsodium. It an old problem, and usenet was the first solution, from long, long, long ago. It should be standardized by now, but I am not aware of it. Instead I see a host of standards, most of them stupid, or inapplicable to my use case, for little parts of the problem.

          It needs to be able to synchronize with a peer on an enormous tree of data by getting only what is new and changed, and needs to prioritize peers that have in the past provided data, and who only want to get a small amount of new data, over leechers who want to download a huge pile of data, and then go offline. These are very standard tasks, which people have been re-implementing from scratch over and over again. No one is using a stable identity system and long term memory of past peer behavior, and I don’t want to create another half assed special purpose implementation of this similar to two dozen other half assed implementations of this, each incomplete, special purpose, and missing half a dozen features that were not urgent in that particular use case.

          Maybe libp2p, on which a lot of people are building. (ipfs and polkadot, among many others.) But I am not that thrilled by it. Do you have any suggestions?

  9. Patrick McDonahey says:

    Any crypto that must store every single transaction since inception… will not succeed.
    Any crypto that is entirely public, with no client capability for resulting in private anonymous transactions… will not succeed.
    Any crypto that cannot sustain at minimum 5kTPS… will not succeed.
    Any crypto that requires the sender to be online with the recipients… will not succeed.
    Any crypto that is not simply cash, or has any form of “governance”, etc… will not succeed.

    Bitcoin and BTC+LN… will not succeed.

    Most other projects are pointless, but there are now a small number of other p2p electronic cash projects out there worth tracking, and even buying on prospective of 10yr timeframe, just as BTC did.

    I’ve not sold out of BTC, but have bought 10yr eqivalents in them, for pennies on the dollar.

    BTC/LN will not succeed because they do not posess the necessary properties of P2P Electronic Cash plus offline transactions. Nor have they proposed any viable solutions to meet those realworld demands. And there are all sorts of monkeyworks in the middle.

  10. A2 says:

    Is this paper of any interest, by the way? PDF is free at the time of writing.

    “We introduce Lurk, a new LISP-based programming language for zk-SNARKs. Traditional approaches to programming over zero-knowledge proofs require compiling the desired computation into a flat circuit, imposing serious constraints on the size and complexity of computations that can be achieved in practice. Lurk programs are instead provided as data to the universal Lurk interpreter circuit, allowing the resulting language to be Turing-complete without compromising the size of the resulting proof artifacts. …”

    https://dl.acm.org/doi/abs/10.1145/3607839

    • jim says:

      Looked this up.

      Looks painfully slow. Turing completeness for snarks is overrated. In practice, your proof generator always has to be driven by extrinsic code, and it is probably best not to hide this fact.

      You are not actually excuting a turing machine. You are actually proving that you know data that has certain properties, some of this data being public, and some of it being private.

      In order to prove relationships, you have to generate a huge amount of intermediate data, and then you construct a proof that the data generated by step n+1 has the right relationship to the data in step n. But your proof engine is not really generating that data, it is being generated by ordinary code in an ordinary computer language, and if you represent your proof engine by a turing machine, you are pretending that it being generated by your proof engine. Which just makes things even more complicated than they already are, because you are hiding ordinary code in an ordinary computer language that the man creating proofs needs to get at.

      Mapping a proof engine onto turing machine execution does not quite fit what you are in fact doing. Your abstractions leak. The mapping leads to weirdness. You have to specially handle and manually workaround the rather large number of cases where reality shows through.

  11. Mister Grumpus says:

    Word’s getting out about Xwitter becoming the GAE WeChat, and thus the GAE Retail Bank, and thus the GAE Panopticon.

    Yet anyone with the chops to pull this off also knows what a “panopticon” is, and what a “zero knowledge snark” is.

    So what happens next? And is this Elon trying to serve the GAE to buy himself some more time? He sure doesn’t need the money.

    • Pseudo-Chrysostom says:

      An everythingapp could theoretically increase the GAE’s capacity for tyranny; but like many other things that theoretically increase the GAE’s capacity for tyranny, it is dependent on Musk’s leadership in particular.

  12. cub says:

    Is it possible to keep ETH decentralized while retaining PoS? Or is another consensus mechanism necessary?

    • jim says:

      Sure it is. But they don’t want to.

      • cub says:

        Are you saying that the ETH developers don’t want to implement a technical solution to combat centralization, or that the current ETH whales don’t want to relinquish their voting power? If the former, what is the solution?

        • jim says:

          The current ETH whales should have voting power, and supposedly do, but they do not.

          So, since proof of stake has been coopted, I propose a new term, proof of share, to do what proof of stake was supposed to do, but does not do.

  13. WW2? says:

    Off Topic: Dropping the atom bombs was unnecessary to end the war with Japan

    Vox Day brought up something I’d never heard before: https://voxday.net/2023/07/30/the-atomic-bomb-was-never-necessary/

    With supporting evidence: https://voxday.net/2023/07/30/japans-surrender-the-trohan-article/

    Claims the Japanese had been trying to surrender for 8 months with basically the same terms that were eventually accepted. The US dropped the A-bombs not to end the war but to demonstrate imperial strength to the rest of the world.

    This feels accurate; WW2 was a religious war, and enemy faiths are not allowed to remain. Plus there’s precedent; the Northern Progs wanted utter subjugation of the South in the US “Civil War”.

    Wondering if anyone more versed in the facts can weigh in on the NRx perspective.

    • jim says:

      Until the Emperor in Cabinet gave the word, Japanese were unable to surrender, because making peace requires cohesion.

      There were substantial elements of the Japanese government that had been trying to surrender for eight months, just as there are elements of the Ukrainian and American governments that have been trying to agree to Russia’s terms for eight months. And did agree to Russia’s terms only for the terms to be ignored. It is not so much that there was conscious intention to break the agreements as that the Global American Empire lacks the cohesion necessary to make peace.

      But these Japanese elements did not have the upper hand, and feared being shot by the die hards. In order to surrender, the emperor in cabinet had to agree to it. Normally the cabinet came to consensus and normally the emperor rubber stamped the consensus of the cabinet. But the cabinet would not come to consensus on peace, even after the nukes were dropped, so the emperor was forced to exercise imperial prerogative, which he very seldom did. It was an extraordinary act, a reassertion of seldom exercised imperial prerogative. And when he finally did lay down the law on his fractious cabinet, elements of the military dropped in on the palace to have a little chat with him, resulting in a whole lot of bullet holes in the palace.

      In order for peace on severely unfavorable terms to go through in the face of determined opposition by a large cabinet faction, the emperor had to exercise imperial prerogative over cabinet dissension and put down a coup.

      The Japanese had captured a pilot, who knew absolutely nothing about nukes, but, under torture by his interrogators, confabulated a huge number of nukes rolling off the assembly lines, being delivered to bases, and the bombers being retrofitted to carry them, being prepared for a mass bombing campaign, because that was what he was familiar with. (In fact each bomb dropped on Japan was a unique experiment hand made by the world’s greatest scientists.) This was reported to the cabinet, that hundreds of nukes were coming and had shown up in large numbers at the airfields, and they still did not agree to surrender.

    • Pax Imperialis says:

      I do not understand the American fixation on the use of nukes during WW2. It was completely proportional to strategic bombing operations at the time. In that regard, the use of nukes was completely normal. Almost no one fixates on the bombing of Dresdan, Toyama, etc which points to cognitive dissonance. Almost no one outside of America cares about the bombing, nuclear or not, either. It’s not like this is an ideological fixation either. Both the American left and right get autistic about it.

      What was completely abnormal about WW2 was the sheer number of bizarre strategic decisions made, likely due to FDR’s international political designs. The Philippians was a complete shit show both in the defense and the liberation. Outright treachery and incompetence by US Generals leading the failed defense was rewarded with Medals of Honor. Later in the war, the US could have simply bypassed the Philippians and gone straight to Okinawa and started the embargo and bombing of Japan a year earlier. Similarly, the US could have bypassed North Africa and taken the nearly defenseless Sardinia and gone straight to Southern France and Italy. There are many other curious decisions that were made during the war that are still shrouded in secrecy, but talking about them often gets seen as conspiracy theory nutjob stuff even though it’s in official US military records and analysis of the time.

      • Pseudo-Chrysostom says:

        FDR worked very hard to make the world safe for communism.

      • Kunning Drueger says:

        The fixation on nuclear weapons, both as a conversational topic/memeplex in the modern era, as well as the organic response to the bombs being dropped on Hiroshima and Nagasaki, arises from the mythology that was constructed to deal with the psychological peril that was introduced when the bombs were dropped. American Society was being rapidly internationalized in a way that had not happened, and specifically not prior to their massive economic expansion. those bombs made a lot of people feel very strongly, in ways they could articulate and apply, but also in ways that they had no capacity to apply, making it akin to a hot poker resting inside your orbital cavity; whatever was going to be done needed to be done quickly. So The managerial revolutionaries used the power of the atom, in a sense, to completely subsume the governmental apparatus of the bureaucracy. The warriors, and this is a very diverse group of people which I am sure you can appreciate, did not really internalize nuclear weapons in a way that could operationalize their inherent desire for status and domination in society. The warrior class took a back seat to the managerial class because the managerial class effected control over the scientific class, who was rightly seen as the most fearsome, capable, and unstoppable appliers of for e in history, using nuclear anything, as well as the plethora of other massive scientific advancements. very quickly on the heels of this, social and ideological changes were instigated, all on the “heat of formation” energy. when warrior Elite, and other elites I imagine, started to Cotton on to what was happening, the managerial elite was more or less ready with a never-ending series of crusades that required the superpower of science. so nuclear weapons must always be the fixation for Americans, as it is what ostensibly makes us the rulers of the world while the understanding thereof is the greatest embarrassment to the country, because we let a bunch of accountancy faggots take over society in a completely stoppable fashion.

        I think it is more than fair to note that the formerly agrarian, formerly isolated, formerly blissfully unaware Americans of the 1940s were just not prepared for what those science experiments unleashed. though much else is talked about in the context of what America is and who Americans are, I think Hiroshima and Nagasaki are probably the most critical single influences on perception in the United States, for a whole host of direct and indirect chains causal factors.

      • TheDividualist says:

        No one expected Japan will surrender. Nukes made them. At least one has to concede that it had great psychological effect.

    • Aidan says:

      Not really. Japan was not “trying to surrender”. Its cabinet of six was deadlocked on whether or not to surrender. Three said surrender, three said keep fighting. So the war continued as usual. One of the war faction said he would flip if good terms could be guaranteed. So they reached out to the USSR (under neutrality pact) asking Stalin to mediate a potential surrender. Stalin was not interested, and instead decided to break neutrality and attack Manchukou. Then the US dropped the bombs. After these two things happened, someone from the surrender faction asked the Emperor to tiebreak the deadlock, and the emperor chose surrender. Not all that useful debating whether it was the nukes or the USSR that spurred the cabinet to take the matter to the emperor.

  14. User481 says:

    You have used three Merkle-type terms here. Only one appears in the literature, the Merkle tree. It appears to me then that you are applying the the idea of a Merkle index to other types of graphs, where:

    Merkle chain* ⊂ Merkle tree ⊂ Merkle directed acyclic graph (DAG)

    Merkle chain example: Bitcoin blockchain*

    Merkle tree example: The Bitcoin transactions in a single block

    Merkle DAG example: Hedera Hashgraph

    Is this correct?

    *ignoring temporary blockchain forks for simplicity

    • jim says:

      Yes.

      It is odd that only “Merkle tree” appears in the literature, since the set of bitcoin transactions form a merkle dag, and that is the biggest and most important use in the world of a graph whose edges are hashes.

      Satoshi confusingly used the term “timestamp server”, that being the major use in his time of a graph whose edges are hashes, but, of course, what he proposed was not in fact a time stamp server.

      Further, a merkle tree is seldom useful unless its leaves are merkle dags, which they usually are. If the literature does not use the term, so much the worse for the literature. They should. And I expect, will.

  15. Chad Boomer says:

    [*not funny*]

  16. SJ says:

    Here’s an article about the shortage of construction workers;

    https://www.cnbc.com/2023/07/29/the-hard-hat-job-with-highest-level-of-open-positions-ever-recorded.html

    I was chatting with some construction Mexicans while at work the other day. The guy with the shovel digging a hole was making $40 an hour. Of course none of us raised in the GAE culture would go work hard digging a hole in triple digit heat because none of us have chaste and obedient wives and children to work hard for. Of course his wife was pregnant with his third child and he was twenty three.

    The end of the article is quite hilarious,

    “More money is going to need to be spent on training additional workers, bringing people into this industry,” Vankudre said. “Because otherwise we are going to hit a point in the future where we’re just not building the things we want to, not because we don’t have the money, but because we don’t have the people.”

    Gee we don’t need actual production guys, we just need more money! If we only have more slips of paper to somehow create more training for the nobody that wants to do this work. Then we could make more paper to give to the no one to do the work we want done.

    I got into it last week at work. As you all know my work is now run by an “AI” program, Dave, which has tiny minute steps for everybody to do everything and it is continually growing. Of course it doesn’t work. Here’s another example. We closed a building and no longer use the building. Dave thinks we still lease it and use it so Dave orders people to go to the building and do things. Because the straight white men who created Dave have all been fired, immediately after they finished Dave, and replaced with gay trans niggers and massively obese single moms, no one knows how to make Dave understand that we don’t own that building anymore and there is no equipment in the building. Dave is very upset that nobody is going to the building and scanning their badges anymore.

    Anyway the executives know that Dave is perfect and will increase production, except it has decreased production. We used to be able to just lie and trick Dave enough for people to get their jobs done which has caused the executives to triple down on Dave. Now production is massively down, like actual production is down approaching 15%, but Dave is reporting that production is actually up about 15%. Dave is reporting that we have all these goods that simply do not exist. These numbers are being reported in the earnings report and the stock price is doing great.

    I’m not even going to get into the fight I had with an executive moron Friday but he told me that Dave literally can’t be wrong because it is an artificial intelligence and it doesn’t know how to lie. I attempted to explain to him that actual real production has nothing to do with Dave compliance, but the executive is of course a total clueless moron. It boggles the mind that people this stupid are now in charge.

    So we are transitioning into creating numbers in Dave rather than the product we actually are supposed to make. At what point does this all collapse? I guess if we just print more money then construction workers will magically appear, just as if we change the numbers in Dave our product will just magically appear. Maybe if we all become lawyers and create more and more billable hours like anonymous fake we can trade all the receipts for anything we could ever want.

    • Mayflower Sperg says:

      “Given we can’t produce more workers in our own country, it makes sense that we would have to find them from other places.”

      Then do what Dubai does: You come, you work, and when the job’s done, you go back home to Bangladesh. Anyone who overstays gets arrested, deported, and barred from entering the country for many years.

      If you’re that ditch-digger and Joe Biden says, “Hola amigo, you’re a citizen now!”, say “muchas gracias” but keep your family in Mexico. If you bring them to the USA, they’ll quickly naturalize and sterilize, with your daughters becoming sluts and your sons slackers.

    • Adam says:

      The modern merchant does not really seem to understand cooperation. At my workplace when I started, the owner was dead set on having one man run material on a certain machine. So one guy feeds the machine then walks around and unloads it. It took some time but I was able to show him if you put one guy one each end, loading and unloading, the machine never stops, and two guys can run three times the material in half the time of one. Plus you free up the machine, and the machines around it that share the space.

      The ability of even the above average to solve pedestrian logical problems has crashed through the floor. Even in small companies, even in construction, there is an extreme lack of order and uniformity. Guys don’t even talk like guys anymore, they talk like women and fags. Men take to order like a duck takes to water. But finding someone who can give and take orders is very rare. I can’t imagine what it’s like in corporate America.

      As far as the Mexicans, another generation and they will be completely converged. They may have the benefit now of the rural effect, where parents and grandparents and families are tight knit and apply a lot of social pressure to marry and stay married, but that won’t last long. All the 8s and 9s are making it into their 30s childless and unmarried.

      I hate to black pill, and I do have faith and hope, but it is getting harder by the day to imagine a future in the west.

      • Your Uncle Bob says:

        At $40 an hour for unskilled manual, I guarantee that Mexican beat out an Amerikaner willing to do that. I know young guys doing tougher work for less.

        We’re at a weird point where customers, stockholders and chamber of commerce pillars of the community positively like seeing likely illegals working on their projects. It makes them think they’re getting a deal.

        On the other hand, and in support of Adam’s point, in my work now I do get a general impression of a generational oppositional defiance disorder. Tell a first time worker to do something, or how to do something, or why something’s done a certain way, or even the easiest best way for them not the company to do something, and some of them do some random other thing instead. You can’t even reverse psychology them because it’s not the opposite, it’s entirely off at an angle.

        But before I go full boomer on this topic, I ask myself how they got that way. Told to stay inside, sit down, shut up and sit still by nice white liberal schoolmarm teachers for 12 or 16 years, and drugged into compliance if they’re too fidgety. Passive aggressive “not gonna, can’t make me, but I’m not gonna come out and say so” is all some of them have left.

        And despite that, pay enough and some of their generation get it together after all. We do have some younger Amerikaners coming along, and my field is still white first, Mexican second with a gap, black third with a bigger gap.

        I know the full solution is status and virgin pussy, but “pay the man” plus a dose of closed borders is still the easiest partial solution. And yet, our elites can’t bring themselves to accommodate even the easy partial solution. Gotta FIREize everything, gotta bring wages down to fight inflation.

      • Magnus says:

        *terrible advice deleted*

  17. alf says:

    I’ve nothing useful to comment about the post.

    But, seems as good a time as any for some housekeeping with regard to the blogroll. My suggestions:

    Removals:
    GraveLord NRX – dead link.
    Bloody Shovel – dead link. I don’t think Spandrell has an active blog?

    Additions:
    Mencius moldbug – https://www.unqualified-reservations.org/ Pretty nice site.
    Aidan’s new blog – https://chevauchee.substack.com/

    Am I missing anything? Maybe Igor Chudov’s substack because of his contributions to covid? I’m not a regular enough reader of his stuff to make that call though.

    • jim says:

      Thanks for the reminder. I have been neglecting the blog roll.

      Chevauchee is great stuff, and Igor Chudov is full of useful scientific information.

  18. deltahedge says:

    The concept of recursive stark proofs is already done by starknet:

    https://medium.com/starkware/recursive-starks-78f8dd401025

    I didn’t fully get your approach but how it differ from that? Just the privacy aspect (utxo + new transactions)?

    • jim says:

      They enable the record of who transacted with whom to be discarded from the reliable broadcast channel, but it still gets sent out to everyone in the clear.

      Also, because they are generating proofs about material that is not organized to make it suitable for generating zk-stark proofs, needs big memory and big machines, leading to centralization. Everyone can cheaply evaluate the proof that the transactions were valid, without needing their own copy of the transactions, but the proof is expensive thus is apt to be produced by a few big centralised players, leading to dangerous concentration of power.

      Their system generates proof that they evaluated other people’s transactions and found them valid. This is the wrong way. Inefficient, wastes bandwidth, concentrates power. The parties that transacted should generate the proofs that each of them transacted honestly and correctly, without broadcasting their transactions.

      Each client wallet should prove its money was honestly acquired from other client wallets that honestly acquired it, No need to broadcast on the reliable broadcast channel how much, or which client wallets. No one should be evaluating other people’s transactions for correctness. Waste of disk space and bandwidth. Scaling problem, privacy problem. Unnecessarily complicated and indirect. It is a wart growing on a wart.

  19. Chad Boomer says:

    [*not funny*]

  20. Jatt Aryaa says:

    [*link to propaganda deleted*]

    • Jatt Aryaa says:

      True, without the ability to larp as Vedic – whites have nothing left.

      Anything that attacks their self-esteem at such a critical juncture is enemy propaganda.

      The idea that the Indo Aryan languages don’t directly descend from Vedic Sanskrit, but something older is nevertheless interesting.

      https://a-genetics.blogspot.com/2023/07/hybrid-model.html?m=1

      Btw, Indus Valley wasn’t dark skinned or south Indian. The closest genetic distance is with Pashtun or Baloch ie loe steppe, low Indian HG, High Neolithic Iran.

      ਅਕਾਲ

      • Fidelis says:

        Who the fuck is funding this particular breed of shill. It’s such an odd script to be running.

      • jim says:

        > The idea that the Indo Aryan languages don’t directly descend from Vedic Sanskrit

        Is nuts.

        When you go further and further back, trying to reconstruct the ur ancestor of languages, there is a lot of noise in your model fitting, so highly motivated reasoning can produce any result one wants for the extremely distant past. It is like seeing flying saucers in the clouds.

        The cities of Bronze age India burned and were flattened at the same time as the cities of Bronze Age civilization in the west and in the middle east burned and were flattened. The old writing was completely lost in India, and barely survived in the West, so, invasion. Which invasion we can now trace in remarkable detail by the genetic evidence. Bronze Age India was flattened by people who originated a few hundred miles from where the people who the people who flattened western Europe originated. The two branches took two separate paths, eventually meeting again in India.

        If you track language ancestry, it duplicates the results you get by tracking genetic ancestry.

  21. Prince Prostate, Ph.D says:

    As a loud and proud gay man, I applaud the NRx plan to ban all pornography everywhere.

    [*deleted for being gross, disgusting, and obscene*]

    • jim says:

      That was quite funny, and what you are parodying is far too real. But also stomach turning.

      • Mayflower Sperg says:

        Would you support a ban on gay, interracial, and cuckold porn?

        • Prince Prostate, Ph.D says:

          Just my position:

          Gay and tranny stuff should be prohibited. The original funny post’s position was that banning straight porn and imprisoning straight men for possessing it may indeed drive some unfortunate men, particularly if they are involuntarily celibate, to the arms of faggots; I explained in somwhat explicit detail who precisely would benefit from preventing men from alleviating sexual frustration by jerking off to the boobs and vaginas of naked women on the internet. Hint: faggots are just waiting for a ban on regular porn to transpire, because they seek to be the sole sexual outlet for miserable men who don’t get laid. I think the post was hilarious and conveyed the idea eloquently and forcefully, but I understand why Jim wouldn’t want that on his blog. Obviously gay and tranny stuff should be banned.

          As for interracial and cuckold stuff, I don’t know if a full ban is necessary – participation in obviously degenerate and unnatural activities (such as filming a nigger fucking your wife) should be deemed low status, and disqualify participants from the priesthood and state positions.

          • jim says:

            > I think the post was hilarious and conveyed the idea eloquently and forcefully,

            Indeed it did. But obviously, unsuitable for this blog, being evidence by example for banning gay porn.

            Yep, just looking at it, one is instantly in favour of banning it. Viscerally digusting. But I don’t want my audience to be instantly in favor of banning this blog.

          • Kunning Drueger says:

            How funny are we talking here? Was it wildly hilarious with disgusting terminology, or was it moderately titillating while drowning in scatological largesse and the sodomite tendency toward incalculable extremity?

            • jim says:

              He was playing a homosexual who is utterly unaware of how completely disgusting he is. Which would be amusingly absurd, if not for the completely disgusting part.

  22. The Count of Montecristo says:

    So does the new uber private and scalable blockchain implementing this make Bitcoin obsolete long term? Also, since everything rolls up into one public index for all the private data, what is the consensus algorithm of that final piece? PoS, PoW or something else? Is that a completely orthogonal issue, or am I missing the implications of what is stated here.

    • jim says:

      Recursive snarks allow sharding. For bitcoin to transition to this, has to introduce shards based on recursive snarks, while the main chain continues as it always has. People then slowly move to the shards. It is doable. To do it, they just have to add validation by recursive snark to their existing contract validation script. They don’t have to turn the existing chain into something completely different. Just add a little door whereby bitcoins can move to recursive snarks and then be moved around on the shards, without ever more data going on the mainchain.

      Proof of consensus is another issue which deserves another post. And it is going to be similarly technical. It is a big issue.

      Proof of work has got to go. Recursive snarks allow all sorts of other proof mechanisms. Filecoin is biggest example, but their proof can only be passed by full sized computers dedicated to their blockchain.

      What you really want to know is how many real users are relying on one transient fork, rather than another, and you get Nakomoto consensus by everyone switching to the biggest transient fork. So, what is a real user? We don’t want an army of shills and sybils, the Hedera problem, but neither do we want a handful of miners with giant data centers and their own power stations, which is the Bitcoin problem (which Monero has substantially fixed, but I doubt that the fix would survive becoming as big as Bitcoin, not that Monero can become as big as bitcoin because of scaling problems.

      So, proof of presence (a real user is synced with the blockchain and his machine responds to requests for data) which is more or less the Filecoin proof of spacetime mechanism), or proof of shareholding. (A real user owns a lot of the primary token of the blockchain, and is represented by a peer that has proof of presence.)

      Going to promote this into a post titled Nakomoto consensus. If you thought this post was rough going, you will likely think that post will be also.

  23. Chad Boomer says:

    Monero was a bust, so I dumped it. Met with a few associates last night at a place called El Hefe on the East side. We cooked up a bitcoin scheme of our own. Gonna call it AlphaCoin! Used the Monero score to seed our initial investment. I was wearing a pair of Tony Lama ostrich steel toes, Roper full length black leather blazer, and $2K wool Stetson. Lost track of how many tequila shots I had after 13. Willie Nelson was playing and we were invited backstage to smoke some dank herb. Kunning Drugger showed up so we made him shine our boots while we bent his chick over. Later Willie let me smash one of his guitars on stage. Woke of the next morning feeling fresh as fuck and did 30 minutes on the stairmaster.

    • Fred Green says:

      Hi all. I hate blacks and women as much as the next person, but I think we should cool it off with any mentions of voter fraud, since this undermines the democratic values which made our nation so great in the first place. I also think we should focus our grievances into the polling station. Think of this stuff like a pendulum, it will eventually swing back around and we will have our turn. This is what is great about democracy. Peace out. 1488, brothers. Don’t forget to follow Fred & Chloe Green podcast on YouTube, rising stars of the alt-right.

      • jim says:

        Allowing this through, but on the internet is difficult to tell sarcasm from genuine insanity.

        • FrankNorman says:

          Given that he shows up out of the blue and starts going on about voter fraud in the middle of a conversation that had literally nothing to do with that, I’d guess either a troll or a shillbot.

          • C4ssidy says:

            Come on. Fred and Chloe. Impersonating a shill. even if perhaps a little inappropriate considering Jim’s claim that they have started flooding

      • Chad Boomer says:

        Voter integrity is a minor problem. We need to build a society free of anti-semitism and racism, find housing for the homeless, cure world hunger and global warming, teach others to be more empathetic and less on capitalism, fight for women’s rights and find a solution to apartheid. Did I mention I’m a complete psychopath and I like to dissect girls. Address the problems with pornography and family unity, promote higher education for the poor, and equity in employment for the disenfranchised.

        • jim says:

          Marginally better. Needs work on funny.

        • The Cominator says:

          Is this channeling the American Psycho character…

          I’ve so far refused to watch the movie because I ah read through part of the book at too young an age, most fucked up thing I’ve ever read and it wasn’t close.

    • Wulfgar Thundercock III says:

      This is the best they can send? Man, must be more cases of Feinstein-McConnell Syndrome going around than we thought.

  24. A2 says:

    Quite a bit to chew on! I read only about half of it this time around.

    Immediate reactions:

    – Somewhat funny that plain trees get adorned with the old joke of being upside down while zk-snarks and zk-starks don’t even merit writing out the acronyms.

    – I didn’t at all like mixing sql concepts (from a series of database standards) with computer science data structures.

    – Structs should probably be explained with some canonical sorting order and/or canonical way to flatten.

    – Is there some way for bad or large actors to reintroduce huge vertexes in a small vertex DAG?

    – Also a lot of background/requirements/etc missing but you did warn about that.

    • jim says:

      > – I didn’t at all like mixing sql concepts (from a series of database standards) with computer science data structures.

      I have been analyzing a variety of ways to implement this architecture, and they all turn out to be closely related from the point of view of sql What is a table in one algorithm is a view in the other algorithm.

      > – Is there some way for bad or large actors to reintroduce huge vertexes in a small vertex DAG?

      Anyone can introduce a vertex as big as he likes, but he is the one that has to produce the proof for it. The stuff on broadcast channel is all defined to be quite small vertices – the typical merkle tree vertex is two hashes and a small bitfield, which is a part of the primary key. I don’t propose merkle patricia trees because I think you are going to be able to program the blockchain in sql, but because that architecture gives us a logarithmically large path of small vertices to prove the data to justify an unspent transaction output.

      There are no end of ways one can structure the merkle dag, but if one is going to structure it to allow people to prove the validity of an unspent transaction output in a logarithmically large number of small merkle vertices, the relationship between the structures is the relationship between equivalent database schema.

      > – Also a lot of background/requirements/etc missing but you did warn about that.

      I tried to list all the requirements that are needed, but I am not going to explain even briefly and cryptically, did I miss a few?

      • A2 says:

        I have been analyzing a variety of ways to implement this architecture, and they all turn out to be closely related from the point of view of sql What is a table in one algorithm is a view in the other algorithm.

        I’m assuming you could rephrase these as simply mappings with certain specified properties? Then again, it might be your usage just triggers my CS autism.

        I tried to list all the requirements that are needed, but I am not going to explain even briefly and cryptically, did I miss a few?

        I’m not really knowledgable in the subject, so some of the stuff comes a bit out of the blue. Probably more obvious to the more experienced reader, so never mind.

        Merkle DAGs: OK, so if I understand it correctly, the cost (proof) of a vertex is paid (only?) by the issuer and you show there is a way to keep the vertex sizes small while the number of vertices is also logarithmic, reducing the cost of the proofs substantially (even asymptotically?).

        • jim says:

          The problem is proving the public reliable broadcast channel. Everything else is private, and the peers submit proofs that their private data is the result of valid transactions whose hash has been registered on the public reliable broadcast channel. Which grows only logarithmically, but is still pretty big, and we want proofs that are logarithmic in the size of public broadcast channel.

      • dave says:

        Yes the usage of SQL Indexes as a method for relating the hashes is interesting, and felt a bit like a throwback. But the lightbulb clicked on when Jim said that at the core a SQL Table/Row/Index is just a struct. At the memory/storage level databases are just an opinionated struct with a normalized way to query them (SQL). Nice.

  25. Sorry Jim, but your crypto currency needs to be fungible enough for Democrats to send a bunch of it to Ukraine, have it laundered and sent back to Democrat campaign funds, and then when Sam Democrat-Democrat gets caught doing it, have the Democrat AG “decide” not to prosecute.

    • jim says:

      Sam Bankman Fried’s scam did not involve any actual bitcoin. He did not understand bitcoin, his customers understood it less, and people who are out of their depth when attempting to do stuff are easily scammed. It involved talking a lot about bitcoin very fast to ignorant people.

      No one got scammed by investing in actual bitcoin. They got scammed by putting their money into government regulated financial accounts.

Leave a Reply