How does Aspire work?

Aspire embeds data into regular gAsp blockchain transactions. To a regular gAsp client, these transactions look like normal gAsp transactions, with one party sending another party a very small amount of gAsp. An Aspire node (which runs the gAsp client along with the Aspire client software will recognize and interpret the data in these gAsp transactions based on specific rules. From this, it constructs its own ledger of Aspire transactions that it has seen on the gAsp network.

So Aspire is not its own Blockchain, but “rides on top of” gAsp?

Yes. Another way to think of it is similar to a Russian nesting doll, where the bigger doll would be the gAsp transaction, and the next doll (inside of it) would be a Aspire transaction. This embedding method is technically known as embedded consensus.

What is “gAsp”?

gAsp is a Proof of Work blockchain that uses scrypt mining and advanced checkpoint technology. gAsp is the combination of several cryptocurrency technologies combined together. In the source code of gAsp you will find original code from Bitcoin, Litecoin, UnbreakableCoin, Peercoin, and eVoxels, and eBoost. You will also find the latest features in crypto technology such as ACP, Segwit, and the RPC used by third party services such as exchanges.

Are Aspire transactions less secure than gAsp transactions?

An Aspire transaction is a gAsp transaction, it’s data is just as secure as any other gAsp transaction.

How do the Aspire nodes stay in sync? What’s to stop one node from disagreeing with another?

As all Aspire nodes run the same code, and all receive the same gAsp transaction data, the ledgers across each node match exactly. Aspire nodes are not like gAsp nodes in that they don’t communicate with each other: they simply connect to the gAsp software and download transactions from it, decoding each one as they go along. In this way, the immense security and computing power behind gAsp is leveraged as the “transport network” for Aspire data.

Given the above, there is no “Aspire peer to peer network” like there is a “Gasp peer-to-peer network”: Aspire-aware nodes comprise a subset of the Gasp full nodes in existence.

What about Sidechains?

Aspire is optimal for mainly higher value transactions and greatly benefits from the security of the main chain. However, if sidechains are ever released, there is no reason that they couldn’t be made to work with Aspire. This is the beauty of Aspire’s embedded consensus technology – it can work with just about any blockchain out there, including sidechain designs.

What kind of addresses does Aspire use?

Aspire uses the same gAsp addresses. As such, Aspire assets (such as ASP, UNB, and all others) may be sent to any gAsp address.

What is ASP?

“ASP” is the native asset (token) of Aspire and some ASP (currently 10) is required as the fee to create new assets on Aspire. It is a technical necessity for adding advanced features to Aspire, which by nature require a protocol aware asset. gAsp can only be aware of gAsp, while Aspire can be aware of both gAsp and ASP itself as well as all assets created on Aspire. 

To learn more about ASP, see about ASP.

Can I secure my ASP and assets in cold storage?

Yes. You can make a regular gAsp paper wallet and store them there. Later, you can sweep the funds into a Aspire wallet, like

Is a 51% attack against Aspire possible?

The short answer is no 51% attacks are not possible on Aspire. The gAsp blockchain utilizes advanced checkpoint technology (ACP) to prevent blockchain hijacking, 51% attacks and double spending. This feature also makes it impossible to perform a rollback on the blockchain. In the past Ethereum has rolled back the blockchain due to a DAO smart contract exploit. In this case of Ethereum, the rollback caused a fork into two chains which are now known as Ethereum and Ethereum Classic. This type of roll back is not possible with Aspire or it’s underlying gAsp blockchain. 

Besides a 51% attack, what are the other risks to consensus?

The Aspire network could be effectively “forked” by a sizable number of people running different versions of the Aspire client that had different “consensus sensitive code” (i.e. protocol code). In this case, if a transaction was read in from the gAsp client software, the differing code may cause two different interpretations of the data, and thus, two different ledger states.

As long as all participants run software that has the same protocol rules (even if it is different Aspire client implementations), this situation will not happen. The reference client includes extensive safeguards that help detect and prevent this from happening.

That being said, the Aspire client is completely open-source. Anyone is able to copy the code and make their own modifications. They can then run their modified version of the software, which technically may generate a different ledger than everyone else. This is similar to Bitcoin itself and Bitcoin Cash. However, to have any impact, that person would have to get others to run it, who would have to trust this individual more than they trust the Aspire development team. This new ledger would not be “Aspire”. It would be a separate ledger with its own protocol rules. Services built on this ledger (such as a block explorer) would not agree with similar services built on the Aspire ledger.

So can the Aspire Team rewrite the Aspire ledger’s history, in an emergency or by decree? How does that compare to the same risks with Bitcoin Core devs?

It’s identical to the case with Bitcoin except that it’s even more secure with ACP implemented. It’s virtually impossible to change the ledger. The Aspire core devs could publish a copy of gAsp Core that does anything, but it wouldn’t change the history of the ledger because of the constant checkpoints sent out to all nodes.

Aspire is 100% open source, with a list of code changes from one release to the next visible for all to see and inspect.

What about support for other blockchains instead of gAsp?

Aspire was built for usage on the gAsp blockchain to solve problems of previously made software. That has always been the case and we do not see it changing. For other blockchains, there are “forks” of the Aspire software, Aspire originally comes from a modified fork of Counterparty rebuilt to lay on top of gAsp instead of Bitcoin. Examples would be Dogeparty for Dogecoin, and Viacoin’s ClearingHouse. We generally encourage forks on other blockchains, especially if they help contribute back bug fixes and enhancements to the main Aspire codebase.

What is Aspire fails or becomes co-opted?

In the event of a catastrophic failure of the Aspire network, Aspire does have the technical capability of “freezing” balances and migrating to another blockchain, with relative ease.

What happens if and when OP_RETURN data is auto-pruned?

Aspire only needs some gAsp full nodes somewhere to have an unpruned copy of the blockchain. As every Aspire full node is also a gAsp full node, this is easily done.

How are blockchain reorganizations (“reorgs”) handled by Aspire?

ACP technology applies again as gAsp never has to reorg to the longest chain. This is because all blocks are processed thru a checkpoint server. gAsp’s chain never attaches to a different chain.


Special Acknowledgement

We give a ton of credit to the Counterparty project. They indirectly inspired us to build Aspire which was expanded by using Counterparty technology.