Archive for the ‘crypto’ Category

« Older Entries

Microsoft turns off the past

Saturday, February 3rd, 2024

For a very long time I have been using a very old windows tool, abandonware, but there is no replacement for it.

I use it to keep a very large pile of structured data and metadata about sensitive information. And this tool suddenly stopped working. After playing around a bit, I came to suspect that the latest windows update had turned it off, probably with a very large amount of other old software. I still had read only access to the data, and I still had a windows machine on which updates had been stopped a short time earlier, and everything still worked fine on the machine running slightly older windows software, only three days older.

I then set to work creating a windows machine which I intended to always run an outdated version of windows, and never to be connected to the internet or the rest of my home network, except through sneakernet. Only to discover that a short time before turning off old software, Microsoft had also scoured the internet of older versions of windows install isos, which starts to look mighty conspiratorial, intentional, and malicious. Also the update happened silently in the background, not with the normal process that involves user interaction, which looks very conspiratorial, intentional and malicious indeed. Software got turned off in a silent hidden background update.

Could everyone please check their hard drives and cd pile for versions of windows install iso predating the current release. They are about to become valuable, also highly illegal, and highly in demand. Also, of course, highly vulnerable to network worms – they will not be useful on the internet, only for running in isolation.

I dumped all the data into non proprietary format – which format did could not contain my precious metadata that structured my very private data. I then zipped it up and encrypted it, and added it to my backup system. I have a plan to manage my data in a new format, but it is going to be a bit more cumbersome and less convenient.

All the new software coming out these days helpfully backs up your precious data in the clear to the cloud. Everyone is installing these wonderfully handy tools that listen to every word you say, send it to the cloud, where an Ai does speech to text conversion, which gives you the convenient ability to say “Siri, play the wheels on the bus song” when the children want entertainment. Today, the television watches you. People are doing this voluntarily, but turning off old software makes it less convenient to avoid, and that this is happening indicates it is going to be systematically and intentionally made less and less convenient.

Does linux fix this? Snap is the first step along the path that Windows has walked – well actually the second or third step. One could argue that systemd and Gnome3 were earlier steps in this direction. Don’t run anything in snap, run it in flatpak. But if you run Ubuntu, strangely difficult and inconvenient to avoid running things in snap.

Just as it has become ever more difficult to access old books, it is going to become ever more difficult to avoid having a television set that watches you. And Microsoft turning off old software looks mighty funny.

Posted in crypto, liberty | 46 Comments »

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

Friday, July 28th, 2023

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.

Posted in crypto | 111 Comments »

Enormous move in bitcoin coming up

Thursday, June 29th, 2023

The good news is that in the not very distant future, everyone who matters is going to be using Bitcoin. The bad news is that if they will be using something resembling currently available software, they will still be net peons, not netizens.

Probably no dramatic price changes next week. Or next month. Maybe not next year. But we are on a big move up that will likely continue going up and up for a very long time.

The dollar is failing as a medium of international exchange.

Cannot do transactions internationally in fiat when the bankers are untrustworthy and untrusted. Cannot do international transactions in gold, because difficult and dangerous to move long distances.

Russia and others have been messing around trying to come up with fiat alternatives to the dollar. They just are not flying. The sovereign of country A agrees with the sovereign of country B for a deal that allows fiat transactions between A and B, and tells the bankers and bureaucrats to work out the details. But a deal that was actually workable would involve bureuacrats giving up power. So they work out a deal in which the bureaucrats of both A and B have complete power. Which means that in practice the merchant lacks the power to actually perform the transaction. You get a bunch of mysterious pieces of paper that are impossible fill out in a valid manner, your money disappears until you have met requirements that no one will explain to you because no one understands them, least of all the bureaucrats that created them, and your money gets frozen and eventually confiscated. So, increasingly, international transactions are getting done in bitcoin. Eventually bitcoin is going to replace to dollar as the medium of international exchange. Because sometimes, increasingly often, there is no useful alternative.

The US dollar is locked in place by Metcalf’s law. For it to fall, an alternative network must achieve critical mass. Bitcoin does not yet have critical mass but it is getting there. People are being forced into bitcoin because the international fiat money system is broken and getting more broken. Dollar dysfunction is likely to force a critical mass into existence. The more people using bitcoin for international transactions, the more useful it becomes for international transactions, which is likely to result eventually in a quite sudden transition.

This foreshadows a huge upmove in bitcoin. Also a huge attack to get state control through the dangerously concentrated miners.

Hodlers are generally betting on Wiemar style collapse of the US$ for everyday transactions, which is probably still some distance away. But a slow motion collapse of the dollar as medium for international exchange is happening right now.

For international transactions, the bitcoin blockchain suffices. The merchant sends you a public key he wants given value, usually over a highly insecure channel likely to leak information to all sorts of people who might want to rob you or just maliciously harm you. You transfer the requested amount of bitcoin to that key. Which should suffice because the transfer shows up on the bitcoin blockchain, which is a reliable broadcast channel, but the merchant frequently wants you to also send him a screen shot of the information that you just published on the bitcoin blockchain, after the transaction has gone through and received a reasonable number of confirmations, on the same insecure channel, because he wants the bitcoin transaction linked to rest of his highly insecure transaction metadata.

For everyday transactions, we need the lightning network. The cryptographically secure Nostr social network has recently been linked to the cryptographically secure lightning network, but the linkage is horribly insecure.

Nostr uses ssh style public private keypairs. Which is not good enough if there is money on the social network, plus people are used to wallet style public private keypairs derived from a master passphrase. People are used to doing it right, and SSH has forever been doing it wrong. And now Nostr is walking the footsteps of SSH. However, the one nostr client that integrates lightning wallet uses wallet style keys, and presumably eventually they all will.

Now if Nostr could be upgraded to use wallet style keypairs, and the linkage between lightning and nostr fixed up, and if lightning’s backup problem was fixed up, we would have a useful system for transactions. Unfortunately the people implementing the linkage were rightly aiming at user friendliness, mass usage, and getting it up in a hurry, and security got trodden under in the rush.

The linkage has now achieved critical mass, which is great, and may well soon show up on Twitter, which would be super duper great, but cleaning up the security mess is likely to be hard and will get harder the more the insecure system is adopted. Still, no one has incentive to do it right, until large numbers of people doing it wrong creates problems. And whatever is wrong with this system, it is a big improvement on what we have now. At present, you can only use nostr with certain peon wallets, though the underlying zap protocol is perfectly capable of supporting the real thing. Unfortunately the real thing is difficult, dangerous, and expensive to set up, which is why Nostr developers have not bothered with it yet.

If you use the standard easy to use lightning wallets, you are a peon. Someone else controls your money, knows what you are doing with it, is selling that information to all and sundry, and you are using your money by his permission. And some of the people buying that information do not like you very much. The real lightning wallets are Lnd and C-lightning. Which you really have to be a unix guru to use. And even if you are unix guru, you are likely to foul up and lose your money.

To use the money safely, you have to have a C-lightning wallet running on a dedicated always on machine, the wallet state has to be continuously backed up moment to moment to a nas running on another machine, (and the wallet is in the clear, and a nas is by its nature not very secure), and the ip address that the lightning network sees your machine at cannot be your home address, because then all manner of bad people know there is money at your home address, which can be physically taken by taking the machine running your lightning node. You are at risk of state authorities deciding that you must be doing something bad, taking your computer with your lightning bitcoin in it, and to get it back you have to prove you were not doing something bad, which is impossible to prove. Or random criminals may just take your computer.

So you want the transactions to go through the vpn, but you don’t want the backup to the Nas to go through the vpn. You don’t want the vpn blocking local network access.

Umbrel and Citadel use Lnd for the lightning network, and are designed for small cheap machines. Unfortunately Lnd is broken, because they never fixed the backup problem. It is only safe to run Lnd on a big expensive highly reliable machine, typically a nas, and not all that safe even on a big expensive highly reliable machine. It is impossible to backup wallet.db, because it is continually being written to, and if your machine dies, you probably have a broken copy of wallet.db. It can only be safely backed up when Lnd has done a clean shut down. And as soon as you start up lnd again, your backup is not only useless, but dangerous.

And wallet.db is where your money actually is.

channel.db is not a backup copy of your money. It is an overly clever and too complicated by half mechanism for recovering money lost in a computer crash, which might or might not work. Will likely recover some of your money. And after you have recovered some of your money, all your lightning channels, accrued reputation and connections are gone.

And if you are running it on a raspberry pi or something similar, you are likely running off an external drive attached to a usb port. And the port connection is going to start randomly failing from time to time sooner or later, probably within a few months. And boom, you have lost all your channels, and probably some of your money. Not to mention rasberries just keep dying.

C-lightning however uses the more reliable and crash resistant sqlite3 database format, and more importantly, allows dual sqlite3 databases. So you have your primary database on your local machine, and a backup with the same name in a different directory on a network drive in the basement on the other side of the house. The backup contains stealable money, and is in the clear, so probably not a good idea to put on the cloud, assuming sqlite will work reliably with a cloud drive, which I doubt.

A “successful” recovery on Lnd is painful, complicated, and no matter how clever and technically savvy you are, you will lose a great deal. A successful recovery of c-lightning will simply resume where it left off.

Lnd is experimenting with a database that is designed to run over the network, as part of their failure recovery strategy. But, last I looked, not yet ready for prime time. And the way Lnd is implemented makes it difficult to implement a reliable backup and restore facility.

What is really needed is a custom database that physically writes a new block on local and remote disks for every lightning transaction, and then from time time creates a packed copy of that data, and then, when the packed data verifies as correct frees up the blocks. Sounds like a big project. And you would want a social network with parity files so that each person kept a parity file (or parity data structure in sqlite) that would enable any one party to recover everything from his seed phrase the way you can with a normal bitcoin wallet. People expect to have a system where they can just download the software from the internet onto a new machine, type in their passphrase, and they get everything back. We know in principle how to accomplish this, but actually accomplishing it is hard.

At present what you need is a wireguard vpn server in the cloud, a dedicated computer on your local hard wired network running wallets, and another dedicated computer hard wired on your network acting as a nas. TerraMaster F4-210 is remarkably cheap nas that can store a lot of data, though you can go somewhat cheaper if you are only going to use the nas to backup your lightning wallet, and therefore do not care about big storage. You can also get a perfectly good fanless mini pc capable of running wallets for a whole lot less than a preconfigured umbrel or citadel strawberry.

To enable people without a pile of hardware on their local lan and good nix administration skills to operate a lightning wallet that is truly their own, and a monetized Nostr identity that is truly their own, without requiring them to do a whole lot work, and risk losing money if they mess up that work, requires a whole lot of software not yet written. We don’t have reasonably easy to use software that makes a man a netizen rather than a peon of big tech.

Demand is coming, while our software is still broken. And no end of people are happy to fill the gap with scam software and peon software. Bitcoin is about to hit the big time, and for international transactions it is good enough, but for lightning transactions, not yet ready, Nostr may well hit the big time, and our software is not ready. If you are on Nostr with a peon lightning wallet, still a peon.

Posted in crypto, economics | 1,580 Comments »

zeek rollups can enable full blockchain scalability and full blockchain privacy

Wednesday, August 17th, 2022

The fundamental strength of the blockchain architecture is that it is a immutable public ledger. The fundamental flaw of the blockchain architecture is that it is an immutable public ledger.

This is a problem for privacy and fungibility, but what is really biting is scalability, the sheer size of the thing. Every full peer has to download every transaction that anyone ever did, evaluate that transaction for validity, and store it forever. And we are running hard into the physical limits of that. Every full peer on the blockchain has to know every transaction and every output of every transaction that ever there was.

As someone said when Satoshi first proposed what became bitcoin: “it does not seem to scale to the required size.”

And here we are now, fourteen years later, at rather close to that scaling limit. And for fourteen years, very smart people have been looking for a way to scale without limits.

And, at about the same time as we are hitting scalability limits, “public” is becoming a problem for fungibility. The fungibility crisis and the scalability crisis are hitting at about the same time. The fungibility crisis is hitting eth and is threatening bitcoin.

That the ledger is public enables the blood diamonds attack on crypto currency. Some transaction outputs could be deemed dirty, and rendered unspendable by centralized power, and to eventually, to avoid being blocked, you have to make everything KYC, and then even though you are fully compliant, you are apt to get arbitrarily and capriciously blocked because the government, people in quasi government institutions, or random criminals on the revolving door between regulators and regulated decide they do not like you for some whimsical reason. I have from time to time lost small amounts of totally legitimate fiat money in this fashion, as an international transactions become ever more difficult and dangerous, and recently lost an enormous amount of totally legitimate fiat money in this fashion.

Eth is highly centralized, and the full extent that it is centralized and in bed with the state is now being revealed, as tornado eth gets demonetized.

Some people in eth are resisting this attack. Some are not.

Bitcoiners have long accused eth of being a shitcoin, which accusation is obviously false. With the blood diamonds attack under way on eth, likely to become true. It is not a shitcoin, but I have long regarded it as likely to become one. Which expectation may well come true shortly.

A highly centralized crypto currency is closer to being an unregulated bank than a crypto currency. Shitcoins are fraudulent unregulated banks posing as crypto currencies. Eth may well be about to turn into a regulated bank. When bitcoiners accuse eth of being a shitcoin, the truth in their accusation is dangerous centralization, and dangerous closeness to the authorities.

The advantage of crypto currency is that as elite virtue collapses, the regulated banking system becomes ever more lawless, arbitrary, corrupt, and unpredictable. An immutable ledger ensures honest conduct. But if a central authority has too much power over the crypto currency, they get to retroactively decide what the ledger means. Centralization is a central point of failure, and in world of ever more morally debased and degenerate elites, will fail. Maybe Eth is failing now. If not, will likely fail by and by.

Eth is full of enemies, but it is also the leading edge of blockchain scaling technology.

Zk-starks and zk-snarks

Zk-snark stands for “Zero-Knowledge Succinct Non-interactive Argument of Knowledge.”

A zk-stark is the same thing, except “Transparent”, meaning it does not have the “toxic waste problem”, a potential secret backdoor. Whenever you create zk-snark parameters, you create a backdoor, and how do third parties know that this backdoor has been forever erased?

zk-stark stands for Zero-Knowledge Scalable Transparent ARguments of Knowledge, where “scalable” means the same thing as “succinct”

Ok, what is this knowledge that a zk-stark is an argument of?

Bob can prove to Carol that he knows a set of boolean values that simultaneously satisfy certain boolean constraints.

This is zero knowledge because he proves this to Carol without revealing what those values are, and it is “succinct” or “scalable”, because he can prove knowledge of a truly enormous set of values that satisfy a truly enormous set of constraints, with a proof that remains roughly the same reasonably small size regardless of how enormous the set of values and constraints are, and Carol can check the proof in a reasonably short time, even if it takes Bob an enormous time to evaluate all those constraints over all those booleans.

Which means that Carol could potentially check the validity of the blockchain without having to wade through terabytes of other people’s data in which she has absolutely no interest.

Which means that peers on the blockchain would not have to download the entire blockchain, keep it all around, and evaluate from the beginning. They could just keep around the bits they cared about.

Unfortunately producing a zk-stark of such an enormous pile of data, with such an enormous pile of constraints, could never be done, because the blockchain grows faster than you can generate the zk-snark.

So, zk-rollups, zeek rollups.

zk-stark rollups, zeek rollups

Zk-stark rollups are a privacy technology and a scaling technology.

Fundamentally a ZK-stark proves to the verifier that the prover who generated the zk-stark knows a solution to an np complete problem. Unfortunately the proof is quite large, and the relationship between that problem, and anything that anyone cares about, extremely elaborate and indirect. The proof is large and costly to generate, even if not that costly to verify, not that costly to transmit, not that costly to store.

So you need a language that will generate such a relationship. And then you can prove, for example, that a hash is the hash of a valid transaction output, without revealing the value of that output, or the transaction inputs.

But if you have to have such a proof for every output, that is a mighty big pile of proofs, costly to evaluate, costly to store the vast pile of data. If you have a lot of zk-snarks, you have too many.

So, rollups.

Instead of proving that you know an enormous pile of data satisfying an enormous pile of constraints, you prove you know two zk-starks.

Each of which proves that someone else knows two more zk-starks. And the generation of all these zk-starks can be distributed over all the peers of the entire blockchain. At the bottom of this enormous pile of zk-starks is an enormous pile of transactions, with no one person or one computer knowing all of them, or even very many of them.

Instead of Bob proving to Carol that he knows every transaction that ever there was, and that they are all valid, Bob proves that for every transaction that ever there was, someone knew that that transaction was valid. Neither Carol nor Bob know who knew, or what was in that transaction.

You produce a proof that you verified a pile of proofs. You organize the information about which you want to prove stuff into a merkle tree, and the root of the merkle tree is associated with a proof that you verified the proofs of the direct children of that root vertex. And proof of each of the children of that root vertex proves that someone verified their children. And so forth all the way down to the bottom of the tree, the origin of the blockchain, proofs about proofs about proofs about proofs.

And then, to prove that a hash is a hash of a valid transaction output, you just produce the hash path linking that transaction to the root of the merkle tree. So with every new block, everyone has to just verify one proof once. All the child proofs get thrown away eventually.

Which means that peers do not have to keep every transaction and every output around forever. They just keep some recent roots of the blockchain around, plus the transactions and transaction outputs that they care about. So the blockchain can scale without limit.

ZK-stark rollups are a scaling technology plus a privacy technology. If you are not securing peoples privacy, you are keeping an enormous pile of data around that nobody cares about, (except a hostile government) which means your scaling does not scale.

And, as we are seeing with Tornado, some people Eth do not want that vast pile of data thrown away.

To optimize scaling to the max, you optimize privacy to the max. You want all data hidden as soon as possible as completely as possible, so that everyone on the blockchain is not drowning in other people’s data. The less anyone reveals, and the fewer the people they reveal it to, the better it scales, and the faster and cheaper the blockchain can do transactions, because you are pushing the generation of zk-starks down to the parties who are themselves directly doing the transaction. Optimizing for privacy is almost the same thing as optimizing for scalability.

State of the art

We are not there yet.

In principle we know how to create a zk-stark that can prove successful execution of an arbitrary turing machine. In practice we do not.

In principle we know how to create a zk-stark that can prove verification of several other zk-starks. In practice we do not.

We have a vast multitude of zk-snark systems that can prove particular things, for example that the inputs to a transaction are equal to the outputs without revealing the transaction.

We need a turing complete zk-stark engine, one that can produce a proof that any algorithm was performed with the expected result, and do not yet have one. There are people that claim to have built them, but their source is closed.

correction added seventeenth of September

https://blog.polygon.technology/plonky2-is-now-open-source/

“Earlier this year, Polygon announced Plonky2, a zero-knowledge proving system that represents a major breakthrough for ZK tech. Plonky2 offers two main benefits: incredibly fast proofs and extremely efficient recursive proofs. It’s a huge leap forward for the ZK space, and we’ve been blown away by the response from the developer community: people want to build on Plonky2.

Today we’re proud to announce that Plonky2 and Starky are open source. They are now dual-licensed under the MIT license and Apache2.”

This is wonderful and unexpected news, but I am overwhelmed by real life events, and cannot take advantage of it until 2023

As of today, all blockchains that do not use zk-rollups are obsolete, all blockchains that rely on everyone verifying everything are obsolete. We now have the solution to the enormous and ever growing blockchain, and the enormous amount of private information it makes dangerously public.

Someone said when Satoshi first proposed what became bitcoin: “it does not seem to scale to the required size.” And ever since then people have been struggling to solve that problem. Now we have a solution.

A closed source zk-stark system is not a zk-stark system, because when Carol applies her verifier to Bob’s argument of knowledge, how can she know what it is verifying?

Further, closed source cryptography seldom actually works. When hostile outsiders take a look at it, usually falls over. They may think they have what they claim to have, but do not necessarily actually have it. They may think that their verifier is verifying the zk-stark produced by their prover, when it is actually verifying something far weaker.

We need a compiler, that, given code for an arbitrary algorithm in a language for the virtual machine, produces a prover that executes the code in virtual machine and also produces a zk-stark proving that the code was executed with the expected result, and the compiler also produces a verifier that verifies the zk-stark. And that compiler has to be open source, without magic secret unexplained codes in it.

A closed source blockchain is not a blockchain, but an unregulated bank, because those who have the closed source could do anything, and a closed source zk-stark system is not a zk-stark system, because not an argument of knowledge, but a mere claim of authority.

We know know in principle how to produce a fully scalable blockchain – but actually doing so is another thing altogether.

How a fully scalable blockchain running on zeek rollups would work

A blockchain is of course a chain of blocks, and at scale, each block would be far too immense for any one peer to store or process, let alone the entire chain.

Each block would be a Merkle patricia tree, or a Merkle tree of a number of Merkle patricia trees, because we want the block to be broad and flat, rather than deep and narrow, so that it can be produced in a massively parallel way, created in parallel by an immense number of peers. Each block would contain a proof that it was validly derived from the previous block, and that the previous block’s similar proof was verified. A chain is narrow and deep, but that does not matter, because the proofs are “scalable”. No one has to verify all the proofs from the beginning, they just have to verify the latest proofs.

Each peer would keep around the actual data and actual proofs that it cared about, and the chain of hashes linking the data it cared about to Merkle root of the latest block.

All the immense amount of data in the immense blockchain that anyone cares about would exist somewhere, but it would not have to exist everywhere, and everyone would have a proof that the tiny part of the blockchain that they keep around is consistent with all the other tiny parts of the blockchain that everyone else is keeping around.

Posted in crypto | 103 Comments »

Current events

Monday, March 7th, 2022

This blog does not normally report, nor pay much attention to, current events, except as they illustrate the long sweep of history.

But, there is a bunch of stuff happening now. Four demons doing a weak-ass imitation of the the four horsemen of the apocalypse are on their way.

First and foremost for me is that the heat on crypto currency is going up, and it looks like the blood diamonds attack on bitcoin may well be imminent. Executive order coming this week. Chances are it will be a big nothing burger, because Shaniqua will be leading the charge against crypto currency, but we will see.

Justification being that bitcoin is being used to get around SWIFT.

Well then, big profits to be made in whatever crypto currency winds up being used to get around SWIFT. When last I checked zk-SNARKs were not yet ready for prime time, and the lightning network was not yet ready for prime time, but it is time to check again.

Getting ready to move again, and not at all sure where to move to.

And on the first horseman, plague:

I have been following Igor Chudov for a little while, and at first it was “Oh wow. The craziest conspiracy theories about Covid are true”

And then after a bit it was more “too long, don’t read. Of course the worshipers of the Mighty and Awesome Covid Demon are evil and insane. What did you expect?”

Looks like the Covid hysteria was demonic, not merely evil. The story now coming out around Covid is not necessarily proof that people who seem to be be demon possessed are possessed by literal demons rather than figurative demons, but it is compelling evidence that modeling them as possessed by literal demons is predictive of their behavior, and predicts better than the rational pursuit of short term self interest by evil means.

Worst Fears Realized: Pfizer mRNA Integrates into your DNA

If the demons keep the upper hand, war with Russia will aim not at victory, but nukes.

With the attention of the Global American Empire on war, it has now become suddenly safer to examine the truth about the Awesome, Mighty, and Holy Covid Demon, but I still see a lot of stubborn resistance and denial, and a heavy handed and hamfisted effort to prevent discovery.

No very dramatic news on the second horseman: War. Globohomo is murdering civilians who attempt to flee Ukrainian cities, and Ukrainian politicians who are trying to get peace, or at least position themselves for a new Russian aligned regime. The Global American Empire is planning a never ending asymmetric war in the Ukraine.

Looking at the movement of Russian forces, looks like they intend to restore the 1914 border between Russian Europe and Western Europe. They seem to be positioning a significant force along the 1914 border. Ukrainians east of the 1914 border mostly speak Russian, of a sort, Ukranians west of the 1914 border mostly speak “Ukranian”.

If they adequately secure the border, either the Global American Empire winds up enduring an unfavorable peace, or escalating to conventional war. Which, with demons literal or figurative running the operation, is likely to go nuclear.

In the long sweep of history, we are not headed for one specific destination, for when glass shatters, it can break in any of a thousand ways, but the pace of events so far is consistent with the continuing trend, in place since 1820, of chaotic and entropic events driven by ever increasing leftism getting faster and faster, despite the fact that we are no longer being bombarded with tales of peaceful dark skinned joggers being attacked by white males, and enforcement of the rituals of Covid Worship seems to have been forgotten. The direction keeps changing, so difficult to make an assessment of how fast movement is happening, except in retrospect.

In 1970 we fell of the track headed towards technological singularity. So far, we still seem to be on track for left singularity, or at least not yet obviously off the track.

Everything is ultimately driven by faith, for an army needs a state religion, and a state needs an army. Our Churches are celebrating gay sex with obscene sacraments, those that do not go along are apt to be burned down, and the police uninterested in finding who burned them down, just as in the Ukraine, people who seek peace, or merely attempt to flee war, are apt to be murdered, while in Russia, for all its grave faults, white men are once again building Cathedrals.

Posted in crypto, economics, war | 290 Comments »

All FIPS compliant cryptographic libraries are backdoored and in the pocket of our enemies

Tuesday, November 2nd, 2021

As are many non FIPS compliant cryptographic libraries. We know from the Snowden leaks that the NSA has spent hundreds of millions of dollars trying to make sure that cryptographic implementations have backdoors supplied for the NSA.

A good way to make money is to construct a cryptographic library, and, if it gets to be widely used, a mysterious and secretive generous benefactor will show up.

To resolve the dragnet problem for passwords, since I cannot help using backdoored software, what I do is have a long master password, from which I generate for each account a ninety six bit random gibberish password.

Any one cryptographic algorithm is usually fine by itself – nothing is wrong with AES256 and SHA256, though there is something very wrong with AES128 as usually used. Used correctly, AES128 is fine, but it never is used correctly.

But any one cryptographic algorithm is useless by itself. To do anything useful, has to be integrated with several other algorithms, an api provided to access and use that integration, and then another library has to use the cryptographic library through that API. And that integration, api, and libraries using libraries, is where the mischief usually is.

Typically you have one flaw, which is obscure, complicated, relatively harmless by itself, and another flaw in something totally unrelated, which is also obscure, complicated, and relatively harmless by itself. You put all these flaws together, with industrial scale precomputation and industrial scale collection of hashes of secrets, and all the encryption falls apart. The Snowden slides would seem to suggest that the NSA has broken the SSL TLS algorithms used in most vpns.

Every major state spy agency, and several private agencies, attempt to collect every face that has ever appeared on the internet, every email address, every username, and every password, and link them together.

The mechanism that the fips compliant libraries, or rather the software that uses them, provide to collect the passwords, and to link them with usernames and email addresses is that they reveal the hashes of email addresses, passwords, and usernames to passive listeners. And the agency collections hundreds of millions of such hashes.

If you have one hash, and you want to try ten billion things to see if one of them gives the correct hash, takes a while. If you have a million hashes, and you want to try ten billion things to see which ones match one of your hashes, takes about the same amount of time. So this form of leakage is primarily useful to those that collect the leaks on an industrial scale. The backdoors are provided to be convenient to those that seek to sweep up all data, not convenient to those who want to eavesdrop a particular conversation.

Let us suppose you want to have free wifi wherever you go.

It used to be that whenever someone signed on with his wifi network, the unsalted hash of his password was transmitted in the clear. So every time someone goes in and out of range of his wifi network, his cell phone transmits the unsalted hash. (Actually it is more complicated than that, I oversimplify, but the end effect is that a passive listener gets the hash of the password.)

This was inconvenient for the agencies, since people do not sign into their wifi all that often, so the Wifi protocol was modified on some slender excuse to continually retransmit the hash all the time, regardless of whether anyone needs it, wants it, or can use it.

So, you have a background process on your laptop collecting these hashes, and once a week or so, you let a process run overnight that tries a hundred billion passwords against a every network you have been in range of. Most of the passwords will be revealed. And now your laptop can sign into a free wifi network wherever you are. Handy.

Which gets interesting if it is the network of a big corporation, because you are now inside their firewall, rinse and repeat similar tricks to get their administrative passwords. Then hold their data for ransom.

If you comment on a WordPress blog, the standard worpress avatar plugins give you an avatar. And somehow, for some entirely inexplicable reason, the blog sends the avatar image, the username, and a hash of the user email address to a central repository. Supposedly the WordPress plugin avatar privacy does not do this, but I was recently informed that it does the equivalent in a more roundabout way, which I have now fixed.

This post was inspired by Let’s talk about PAKE, a post on how to do login by password correctly – so that the server does not know, and cannot learn, the password. Using the opaque zero knowledge protocol, the server never knows the password or the hash of the password, and the client never knows the per user salt, or per user key stored on the server, no hashes of interesting information are exchanged. If the server is evil, or the bad guys seize the server, everything is still encrypted and they have to run, not a hundred million trial passwords against all users, but a hundred million passwords against each user. And user can make the process of trying a password far more costly and slow than just generating a hash. Opaque zero knowledge is designed to be as unfriendly as possible to big organizations harvesting data on an industrial scale. The essential design principle of this password protocol is that breaking a hundred million passwords by password guessing should be a hundred million times as costly as breaking one password by password guessing. So this post is not about the opaque password protocol. It is about why it is needed.

Posted in crypto | 197 Comments »

Bitcoin time

Saturday, October 23rd, 2021

I have been diversifying from Bitcoin to ADA, because I was profoundly unhappy with Bitcoins scalability, and with its implementation of the lightning network, and I recommended that other people do so.

This turned out to be a bad idea.

The bitcoin lightning network substantially eases the scaling problem for an order of magnitude or two growth, after which scalability is likely to start biting again.

The bitcoin lightning network’s problems appeared to be insoluble to me, because of the way bitcoin works, and because I was just not seeing the will or coherent organization needed to fix them.

The taproot update to bitcoin, however, makes it possible to fix the lightning network, and suggests the existence of will and organization capable of fixing it, and with intent to do so. I conjecture that the recent rise in bitcoin is substantially driven by this prospect.

The biggest immediate problem with the lightning network is unrelated to the issues that taproot addresses: backup. Backup of your lightning network is broken, unless you are merely the client of some big node,.

The big point and big value proposition of cryptocurrency is that you don’t have to suffer client status, with all its grave costs, dangers, and inconveniences. It is client status that is the problem that bitcoin was originally created to fix.

To recover your lightning wallet you need both the master secret and the current state of your lightning wallet. Which you probably lost in the crash. Backups will not work, because the state of your lightning wallet, unless you are a mere client of a single important node, is likely to change frequently and unpredictably. The current backup solutions are a collection of complicated half assed workarounds which are likely to mostly work most of the time, provided you know who all your counterparties are, they are still around, and they are honest, well behaved, and well intentioned.

The correct solution is that every time your wallet state changes, it should send a copy of the state change, not the entire state, just the change in state, encrypted to a secret that only the possessor of the master secret can generate, to a couple of backups in the cloud.

Then if your lightning wallet crashes, you could recreate it from your master secret by re-running all the state changes from the beginning.

I don’t know why this was not implemented. Perhaps it is just that they had, and have, more pressing problems to deal with, but now that there is substantial, and rapidly growing, money in the lightning network it becomes a lot more pressing. I intend to go lightning, once backup is adequately addressed, and am going back to bitcoin right now.

Posted in crypto, economics | 464 Comments »

Where we go from here

Saturday, January 23rd, 2021

Electoral politics is dead, though its corpse will continue to be paraded about for a considerable time. It will not be revived for a very long time, for a live Republic requires a virtuous elite, and creating a virtuous elite is a project that requires a virtuous King, and a few generations.

I hoped and prayed that Trump would retain power – either as president, or as leader of the resistance, and I lost several bets that he would. Also my investments were to some extent premised on him retaining power.

On the other hand, I have also been making preparation for a more complete disappearance, and so far, it looks like that may not be needed for a while.

I have for decades predicted war, democide, or genocide around 2026 or so, and have never shifted in that prediction. On the whole, things seem to be moving as expected, at about the rate expected. Trump retaining power might have eventually caused me to change that prediction, but a lot more would have had to happen following him retaining power for me to change that prediction. It took Augustus Caesar a decade or so after becoming dictator to sort things out in Rome, and he had death squads and an army at his back. Had Trump successfully performed the coup or started the civil war that I expected, it would have been only the small beginning of what is needed to reverse the decline.

When a holiness spiral goes this far, it takes a lot to stop it. And the further it goes, the more it takes. And even after it is stopped, you still have a big problem, as Sulla had a big problem, and Augustus Caesar continued to have big problems, because you have a degenerate elite, as Russia had after communism collapsed.

I am not necessarily predicting armed conflict in 2026 or so to be the end of our troubles – it could well be the beginning of the end of our troubles, but it could be the beginning of even greater unpleasantness to come, the start of a long dark age for the white race, which is likely to be a long dark age for all races.

Trump is delusionally attempting to appease his enemies. He should be running away. A Trump restoration could only happen after the pattern of the Rwandan genocide, when the exiles returned to conquer a grotesquely dysfunctional and murderous government. And, on January the sixth, Trump revealed himself as not the man for that. He could still become the man for that, but every time he opens his mouth, this looks less and less likely.

In the near future, we can expect the deep state to struggle with the radical left for power. (The Republican party will lose all relevance) Everyone, including the radical left expects the deep state to win and restore normality, but this is normalcy bias. The establishment left lacks cohesion, so each member of the establishment left will try to make his own deal with the radical left at the expense of the rest of the establishment left.

We are now in a situation paralleling the overthrow of Czar and the overthrow of King Louis the sixteenth. The deep state expected to continue governing Russia and France, without the inconvenience of a King bothering them, but was soon in for a big surprise.

Everyone in the deep state thinks that with the democratically elected president out of the way, they will be running the country, but there are far too many of them, they are all going to cut a deal with the radical left, and they are all going to find themselves with the short end of the stick in their deals.

Eventually the leftism spiral will be ended by a Napoleon or a Stalin. If we are lucky a Cromwell. Then leftism will slowly empty out for lack of new applecarts to knock over. At which point an alternative religion will gain mass traction. And that new religion will need to ready itself for eventually becoming the state religion, as progressivism is now the state religion.

The time for electoral politics is over, and the time for an alternative mass religion is not yet. It will likely take quite some time before our enemies have finished destroying each other, so what do we do in preparation for our enemies to destroy each other?

We preserve the truth of Gnon in preparation for the day where it is possible to compete with the state religion, which will become possible only after it empties out of genuine zeal and faith, which is not going to happen until a Stalin restrains it from knocking over any more applecarts, or all applecarts are utterly destroyed.

The time for an advocacy movement is not yet. We are an analysis movement – Trumpism was an advocacy movement, and I had high hopes, but it was crushed, and anything slightly resembling it will be crushed harder.

The time for advocacy will be when leftism empties out, which is not going to happen with applecarts falling over everywhere.

Our key issue is patriarchy, and each of us should promote it at the individual level, by being alpha in our interactions with women, and by telling our women that this is God’s will, and by approving or disapproving of individual associates according to whether their conduct undermines or supports their family and our own.

Some time ago I was at a party, and my host had failed his wife’s shit test, and was angry and despondent. I said “Why don’t you just tell her to do it your way”, to which he despondently replied that it was over and settled. “It is done”. He is blue pilled, and I doubt a lecture on Game, Game Theory, Evolutionary Game Theory, and Evolutionary Psychology would have gone down well, even had I been sober enough to give it, and he sober enough to understand it, which we probably were not. So I just said “A man should be King under his own roof”, and moved on, letting the matter drop. A few minutes thereafter, he passed the shit test with flying colors, his wife eager to please. Perhaps it was that I simply simply rejected the false and evil morality that was poisoning his will and this gave him the strength to do what was right. The left pretends that everyone agrees with their anger and lies, and people believe it, believe that everyone agrees, because no public doubt is permitted, but if one man does what is right, good, and true, and will say to his friends that it is right, good, and true, people that are hurting from the conflict between leftism and reality can feel it in their hearts.

The state has so many evil laws, that it is generally unable to enforce them against those who live according to the will of Gnon, and are confident in the righteousness of so doing.

Leftism is getting brittle, because the ever greater gap between leftist doctrine and people’s lived experience is hurting people. But the child who cries the that emperor has no clothes is not going to cause leftism to fall over as long as fresh applecarts remain for leftism to knock over. It is not public advocacy time yet.

We also need to address the namefag problem and the destruction of the market economy using cryptographic means. Bitcoin was huge step in the direction of fixing the market economy, making possible transactions that are increasingly obstructed by laws and regulation.

There were many attempts on cypherpunks to address the increasing dysfunction of money and accounting. They failed until Satoshi created bitcoin. Digital gold failed because the government simply seized the backing. Bitcoin was successful, but it is a prototype that is prematurely being used as the final system.

We need to build the technology for a semi underground market economy and name system. Satoshi’s blockchain, namecoin’s blockchain, and the Jitsi name system are prototypes for what is needed.

Nothing that matters has changed in social technology, with the big and important exception of double entry accounting and corporate form that it made possible.

I expect that the blockchain and triple entry cryptographically signed accounting will also make an advance in social technology possible, changes that the ICO prefigures, but right now our problems are with social technology that has not advanced since the time of Greece and Rome. Building the things that make new social technologies possible are a step towards the recovery of old social technologies.

When the time is ripe, we will need to reboot systems that are very old, and have been broken. At the same time, while waiting for the conditions that will make a reboot possible, we need to work on the social technologies of the future. Which is corporations as sidechains on the blockchain, for these technologies will make it possible to preserve truth, technology, and the market economic order through what may be well be a very long dark age.

We preserver reality, truth, and respect for Gnon, and attempt to preserve the market economy underground.

We are in an environment that is not only hostile to the vast majority of men having sex, and hostile to all men having children, but also hostile to the market economy. Vox Day’s corporate cancer is devouring the market economy. Corporations are being repurposed from producing value to producing holiness.

We are now using white designed but East Asian built cpus, because corporate cancer has devoured our fabs, and are likely to soon be using Chinese designed CPUs. People are starting to use the Exynos SoC, which is a Samsung design built in a Samsung fab for a Samsung built and designed CPU, and the Media Tec chips, which are designed and built in Taiwan. If I was building a home security system today, it would be running on Taiwanese designed and built CPUs and SoCs.

White people lost the fabs to corporate cancer, and are starting to lose the software, chip design and chip architecture. To resist this trend while the very holy progressives are still in charge of the state religion, we need separation of information and state – which is part of the same program as the faith of Gnon, for the faith of Gnon requires us to protect the truth from a state and state religion that is hostile to truth.

While our ultimate goal is a state and state religion that enforces truth and truthfulness, as Charles the Second’s men at arms protected the Royal Society from Puritan attempts to forcibly deplatform them, for the duration our goal is agorist, to build social media platforms, economic platforms and market platforms that are not state controlled, as the Royal Society existed underground during puritan rule as the Invisible College. Agorism has no answer to large scale organized violence, and neither did the Invisible College, but after the Restoration, the Invisible College became the state sponsored Royal Society.

I may be blogging less for a while, because I am working on the design document of a very large project, and a very small foundation stone of actual software for that project.

Posted in crypto, culture, politics, war | 1,155 Comments »

Stormfront is a honeypot

Sunday, October 29th, 2017

Stormfront uses Google Analytics. Google Analytics runs an alarmingly large pile of obfuscated javascript code on your browser that if you visit Stormfront, can very likely uniquely identify your browser, even if you are accessing Stromfront through Tor to anonymize your IP.

Thus, you visit Stormfront, carefully using a fake name and an anonymized IP. And then you visit Youtube with the same browser, and Youtube says that you cannot watch this video unless you sign in with your Google account, which Google goes to alarmingly great lengths to link to your true name, thereby linking your browser fingerprint to your true name.

Tags:
Posted in crypto, politics | 43 Comments »

How to do cryptocurrency right

Sunday, October 8th, 2017

Proof of work tends to be inherently slow, has inherently high transaction costs, and the miner’s interests are not identical with those holding currency as a store of value and those using currency as a medium of exchange.

Proof of stake is nontrival to get right. It is a form of the infamously difficult to understand (and infamously difficult to program correctly) Paxos protocol. The Paxos protocol has the great advantage over the proof of work in that after an unpredictable and possibly large time, it announces a definite result, whereas with the bitcoin proof of work protocol, no result is ever final, it just becomes exponentially probable.

Ignore the carping that proof of stake is inherently flawed. Any implementation of proof of stake that is easy to understand is likely inherently flawed, that being the infamous nature of Paxos.

Bitcoin was genuinely decentralized from the beginning, and over time became more centralized. Big exchanges and a small number of big miners are on the path to inadvertently turning it into another branch of the oppressive and corrupt government fiat money system.

The new altcoin offering are for the most part not genuinely decentralized. They have a plan for becoming genuinely decentralized some time in the future, but the will and ability to carry the plan through has not been demonstrated.

Assume that, instead of everyone being a peer, we have few dozen or so peers, the peers distributed among several nuclear armed jurisdictions, and each peer has a hundred million or so clients, and each peer stores the entire blockchain forever.

OK, we are talking rather large peers. A terabyte of storage, a hundred dollars worth, will keep one of them going for a week. Say two terabytes for redundancy. I don’t think cost of storage is going to be a significant problem.

Scaling, however, is the hard problem. Making enormous amounts of storage actually useful and effective is the problem. The amount of storage per client is absolutely insignificant. The amount of bandwidth per client is absolutely insignificant. Having a useful connection between enormous numbers of clients and enormous amounts of storage via enormous amounts of bandwidth is the hard part.

Prompt response is another problem. It inherently takes time, and potentially large and unpredictable time, to reach consensus on the blockchain.

We can, however, have fast trust base responses followed by consensus: Since the peers are pretty big, you can trust a peer for your payment during the short time it takes for consensus to settle.

The way this would work is that every client is hosted by a peer. If his host should crash, or turn evil, he can move to another peer, though during the move he will not be able to make fast transactions. When he makes a payment, the peer hosting him testifies that this is not a double spend, and the payment is instantly flagged to the recipient as cleared – but it does not get flagged as settled, and the recipient cannot spend the payment, until it gets incorporated into the blockchain consensus, about twenty minutes later. Since the peers are big and long lived, you can trust them with your money for half an hour or so, and if you don’t want to trust them,, or you don’t trust some of them, you just wait for the transaction to be incorporated into the consensus.

Tags:
Posted in crypto, economics | 27 Comments »

« Older Entries