Skip to content

Instantly share code, notes, and snippets.

shelby3 /
Last active Mar 7, 2020
Did The Plane Flyover The Pentagon?

Plane Flyover; Explosives Planted Inside The Pentagon

The flight data recorder and credible witness testimony are compelling evidence the plane flew over the Pentagon on 9/11.

These facts explained below have been hidden under our proverbial no(i)se for 17 years.

Every citizen on earth has a civic duty to study this information. The intentional wars and destabilizations that have followed 9/11 for example in the Middle East, the migration invasions, the divisive politics tearing apart the U.S.A, as well as the possible coming nuclear war between the USA and Russia has been perpetrated by the global elite[mafia] who masterminded 9/11. I wrote:

This cabal is the p

shelby3 / Get Ready for a World
Last active Dec 3, 2019
The future of money, currency, governance, economy, and civilization is to be determined by the confluence of public confidence, politics, culture, economics, and technology.
View Get Ready for a World

Get Ready for a World Currency


The future of money, currency, governance, economy, and civilization is to be determined by the confluence of public confidence, politics, culture, economics, and technology.

shelby3 / Excerpt from Bitnet’s
Created May 7, 2017
Excerpt from Bitnet’s whitepaper
View Excerpt from Bitnet’s

@cryptorebel wrote:

@hankdasilva some people think mining will become more decentralized over time:

Ah sorry I debunked the PoW as space heaters in my unpublished whitepaper:

5.1.1 Specialization

As noted in the sub-sections Selfish Mining Example, Proof-of-Work on CPUs, and Proof-of-Work as Space Heaters, economies-of-scale enable opportunities for specialization of ASICs, data center cooling systems, etc., which foster lowest cost miners that have much higher profits and pro rata rate of return-on-investment than the marginal miners. This is a power vacuum feedback loop because the economies-of-scale grow faster for those with more economy-of-scale.

Proof-of-Work on CPUs
shelby3 /
Last active Nov 26, 2016
Section 5.1 Dictatorship

5.1 Dictatorship

The subsequent sections will explain in detail why PoW is posited to be a winner-take-all power vacuum, and the harmful effects anticipated.

Unlike for example a farm or factory which have a diminishing rate of marginal utility of economies-of-scale, i.e. economies-of-scale above which no further increases in pro rata profit are obtained, the marginal utility of additional economies-of-scale in PoW hashrate do not diminish until greater then 50% of the systemic hashrate is consolidated, which is the winner-take-all outcome.

Power vacuums are disequilibria that fail because they are incongruent with the fact that small things grow exponentially faster than large things.[34] Most small things don’t grow large enough to become stable large things, e.g. the competing saplings in the forest, because they have more competition and friction. Analogously most of the lower middle class and poor don’t grow wealthy because a higher portion of a lower income is budgeted for food instead of saving

shelby3 /
Last active Nov 23, 2016
Section 6. Delegated Proof-of-Stake

6. Delegated Proof-of-Stake

Dictatorship: Exponential or power-law distribution of the control of stake is a power-vacuum trending toward a winner-take-all disequilibrium.

Censorship: Not a permissionless free market to add transaction events and stand up consensus ordering (i.e. delegate witness) nodes. Eventually the winner-take-all cartel of power-law distributed whales are in control.

Monopolistic: Funding for delegate witness is not set in a competitive free market of transaction fees. Instead eventually the winner-take-all cartel of power-law distributed whales decide both the set witnesses and the level of funding generated from minting supply, thus effectively deciding how much to pay themselves by debasing the money supply.

Synchronous: No asynchronous concurrency of transaction ordering for enhanced scaling, throughput, resiliency, and liveness. Only the witness that produces the next block may add transactions during the block period, and all transactions must be propagated

shelby3 /
Last active Nov 23, 2016
Section 5.1.2 Invisible Majority Hashrate Attacks
5.1.2 Invisible Majority Hashrate Attacks

The majority hashrate (aka “51%”) attack which orphans some or all of the minority’s blocks is not objectively distinguishable from a random result. Some blocks are orphaned and others are not, yet there is no way to objectively prove from the information stored in the blockchain that a 51% attack was present. Clues might be indicative of a 51% attack such as a higher orphan rate, but this can also be caused by network delays which is what the 51% attack masquerades to other mining nodes. Tracking down nodes which are participating in the attack is not plausible because IP addresses and even pools can be a Sybil attack.[41] There can’t exist an objective perspective in the Byzantine Generals Problem (aka “BGP”) without a total perspective.[42] Yet a total perspective is not a BGP.

Unless a minority hashrate miner has, or is in a pool that has, at least ¹/₃ of the systemic hashrate, they won’t be able to triangulate to differentiate between random bad luck or

shelby3 /
Last active Nov 23, 2016
Section 5.3 Monopolistic

5.3 Monopolistic

There is no possible solution to the block size dilemma in Satoshi’s proof-of-work design, except for a power vacuum driven monopolistic outcome.

If the block size is constrained and when the transaction volume exceeds the block size, a fee market is created in which lower valued transactions will be delayed (some indefinitely), i.e. “crowded out”, because the more high valued transactions (with their presumably higher fees) take priority. Above some levels of transaction volume for a given block size, some threshold of lower valued transactions will not be added to a block indefinitely. And the constrained block size that causes this undesirable outcome may be necessary to prevent consensus incentive incompatibilities[45] (i.e. disincentive to form consensus, thus forking and other chaos) when minted block rewards cease.[46]

If a) the block size is unbounded, b) the minted block reward is significantly greater than the average transaction fees per block, and c) no mining ca


5.4 Synchronous

PoW’s lack of concurrent (aka asynchronous) partial orders as elaborated in the sub-section Aliasing, doesn’t directly negate resiliency and liveness, because every mining node is eligible to produce the next block. But the resiliency and liveness provided by the availability of a diverse (in geography, performance, policies, cost structure, etc) plurality of miners competing to produce the next block is always diminishing as explained in the sub-section Censorship.

There is no asynchronous (i.e. concurrency of) transaction ordering for scaling transaction volume throughput. Only the mining node (possibly a pool) that produces the next block may add transactions during the block period, and all transactions must be propagated to every node. The transaction throughput can theoretically be increased by increasing the block size, although this creates other scaling limitations such as O(n²) propagation to, and validation load on, all nodes― even those

View PL Design

So Rust has global references ownership rules, which only allow one (borrowed) mutable reference to the same object to be active in the current block scope. The objective is to prevent race conditions on the object. But from the discussion we had on the forum, a DAG tree of disjointness is not a general model of imperative programming and afaics in the general case requires dependent typing (which is known to exclude Turing-completeness). Thus I abandoned Rust's global borrowing rules, because it seems like a pita of false promises that is rarely (20% of the time?) applicable.

But I [proposed a more localized

View PL discussion with

jl777 wrote:

why not have the way you allocate the memory determined how it behaves?

In a garbage collected (GC) language such as JavaScript, you don't actually ever explicitly allocate and deallocate memory. Thus we avoid the bug of crashing when a pointer points to memory that has already been freed, or the memory leaks due to forgetting to deallocate memory. GC languages can still have semantic memory leaks though, such as forgetting to remove an event handler. Automatic reference counting pointers have the flaw that they memory leak where there is a circular reference (pointer points to some structure which contains a pointer which points back to the struct that contains the first pointer).

So GC is much easier for the programmer than manually tracking memory allocation and deallocation. But it has one disadvantage which is that it requires up to 5X the memory to achieve the same performance, and the mark-and-sweep pauses can lockup the machine for many seconds. There are ways to improve the GC. The m

You can’t perform that action at this time.