Whitepapers

Want a more indepth understanding of PascalCoin? Below you can download the Whitepapers which go into greater detail on the inner workings of PascalCoin, including the groundbreaking Safebox technology.

Download Whitepaper V2version 2.1, June 2017

Download Whitepaper V1version 1.0, July 2016

Extended Information

Infinite Scaling

Infinite Scaling is the ability for a cryptocurrency to run for an infinite period of time using the same amount of storage (at a constant throughput). All other cryptocurrencies will eventually fail over a long period of time since their history of transactions become so large that new nodes cannot synchronise and existing nodes run out of storage, among many other failures. PascalCoin is the first cryptocurrency to solve this major shortcoming.

Storing the Flow rather than the History of transactions

PascalCoin only keeps the last 100 blocks of the blockchain whilst retaining the cryptographic security of the full blockchain. It achieves this by using the SafeBox to keep track of user account balances and ownership whilst simultaneously retaining the aggregated proof-of-work difficulty within the SafeBox itself. In order to forge a SafeBox, it would require re-mining the entire history of blocks even though those blocks are no longer known (even by the network).

As a result, PascalCoin does not store the infinite history of transactions, only a short recent history of them. In this sense, PascalCoin stores the flow rather than the history of transactions, whilst retaining the full cryptographic SPV security of the history.

Reliable & Instant Unconfirmed Transactions

Since PascalCoin is state-based currency the security guarantees of 0-confirmation transactions are much stronger than in Bitcoin and other UTXO-based currencies.

Whilst large payments should always wait for a reasonable number of confirmations, merchants will be able to accept 0-confirmation PascalCoin payments for small purchases thanks to the (planned) Double-Spend-Detection-Service. This service queries nodes throughout the planet to see if a double-spend has been detected. If after 5 – 10 seconds, no such double-spend has been detected, merchants are almost assured that the 0-confirmation payment will clear. Good enough for Coffee.

No Need For Lightning Network

As a direct consequence of reliable 0-confirmation transactions, there is no need for a Lightning Network in PascalCoin since 0-confirmation transactions are faster and their security guarantees almost as good – sufficient for micro-payments and everyday-commerce.

Account Names and Types

One of the key new features of PascalCoin is that accounts can have unique names which are publicly visible, much in the same way as the domain names system. This allows a user to receive funds to their email address or chat moniker.

It allows a shop to receive payments to their domain name or brand name. Payments still refer to accounts via numbers, but the name is used to lookup the account number just as a domain name is used to lookup an IP address.

More importantly, account names and types serve a fundamental purpose in Layer-2 applications and Monetized APIs. For example, the account name could serve as a chat room name or a forum name. Account types further serve as a means to distinguish accounts for their use-case. For example, browsing accounts with type = 2 could be like browsing a list of chat rooms. How users interact with such Layer-2 applications is via Monetized API's described below.

Commoditization of Address Space

In almost all other cryptocurrencies, new users can simply create a new address for themselves at will. This creates an infinite address-space which can quickly bloat the blockchain even though the number of users remains constant.

If the address space was instead made finite, it becomes a limited resource able to be commoditized. This is how PascalCoin accounts (PASA) operate.

The accounts are limited, but any public key can be associated to it. This creates a natural space-saving mechanism since the chain is not littered with unneeded or used keys. It also disincentivizes spammers, since spammer accounts would be naturally limited and thus easily identifiable/blockable. Also, and most importantly, commoditization of the address space facilitates the SafeBox structure itself which is the key component to achieve "Infinite Scaling".

Assets, Sub-Tokens and Smart Contracts

By leveraging PascalCoin's Layer-2 architecture, it is possible to achieve Assets, Sub-Tokens and Smart Contracts in the same way Rootstock achieves Ethereum over Bitcoin.

Running Ethereum Virtual Machine over PascalCoin would be possible by maintaining a side-chain pinned to an account (as Rootstock does). Transactions to this account would embed Layer-2 protocol commands that govern the EVM side-chain.

Interestingly, Sharding could be achieved easily since independent EVM side-chains could run bound to separate accounts. Inter-shard communication would simply be transactions between these accounts. The rest of the network would not really be impacted by the large volume of transactions since the natural process of Checkpointing discards these transactions after 100 blocks. Only side-chain users would bother to record all account transactions in order to validate their side-chain.

Monetized API's

Due to reliable 0-confirmation transactions, PascalCoin allows a new form of decentralised application coined here as "Monetized APIs". In a Monetized API, PascalCoin accounts serve as "ports" that listen/send "monetized-messages" to other "ports".

It achieves this by repurposing an account as a named message-queue and by utilising Operation Payloads. In PascalCoin, operations can carry any arbitrary 256 byte payload of user-data. Payloads can be public or encrypted.

This unique capability allows operations to embed "Layer 2 protocols" in much the same way that HTTP lives inside TCP. The difference here is that the protocol messages carry a financial weight, and as a result, can be used to conduct granular economic communication suitable for algorithmic/autonomous/micro-commerce scenarios. For example:

  • Pascal Chat

    An account can serve as a chat room where the the account name is the room name. Operations payloads to the account can contains the user's chat message. The users handle would simply be the sender's account name. These chat rooms can be used for trading goods and services in a decentralised manner. Anonymity can be enhanced via other Layer-2 applications. Users can settle payments for goods by attaching funds to private messages between themselves.

  • Monetized Content

    A PascalCoin browser-plugin that pays content providers for content on-the-fly. The payment itself contains info to allow the server to unlock the content for the browser. This could be used for monetizing news, blogs, ebooks and social media content.

  • One-click e-commerce

    a one-transaction e-commerce site who's shopping cart is reduced to a single "Payload Code". The buyer merely sends a PASC payment containing the Payload Code, and when received by the merchant the order is executed for the buyer.. No credit card numbers or complex payment-gateway integrations were required.

  • Anonymity Mixers

    accounts can receive funds from other accounts and then then re-send those funds using complex financial routing information encrypted within the sender's Payloads. The mixer can split/delay/relay/loop payments arbitrarily thus sufficiently obfuscating the sender, receiver and quantity from taint analysis.

  • Layer-2 Side-Chains

    since messages to/from an arbitrary account X can be used as a message queue, it is possible to construct Layer 2 Protocols for managing a side-chain by monitoring messages to X. The side-chain's validity/state is governed by the Layer-2 protocol embedded within these Layer-1 payloads. The owner of X serve as an authority on a mono-federated side-chain suitable for Dapps. Owner-free (or non-federated) side-chains can be constructed by associating a proof-of-burn key on an account. Federated side-chains will be possible when Schnorr multisig is implemented whereby members of the federation will be comprised of the Account signatories. An example of an actual Monetized API, and the first one ever created, is GetPasa.com. It works by listening on account 77-44 for incoming transactions of 10 PASC or more. When a transaction is sent to 77-44 containing 10 PASC or more, it's payload is examined for the presence of a public key. If nothing is found, transaction is discarded. If a public key is found, the service then finds a free account in it's inventory and send it to the key it found. This allows new users to purchase an account in a one-step process that sends a single message containing the order and payment combined.