- How does Aspire work?
- So Aspire is not its own Blockchain, but “rides on top of” gAsp?
- What is gAsp?
- Are Aspire transactions less secure then gAsp transactions?
- How do the Aspire nodes stay in sync? What’s to stop one node from disagreeing with another?
- What about Sidechains?
- What kind of addresses does Aspire use?
- What is ASP?
- Can I secure my ASP and assets in cold storage?
- Is a 51% attack against Aspire possible?
- Besides a 51% attack, what are the other risks to consensus?
- So can the Aspire Team rewrite the gAsp ledger’s history, in an emergency or by decree? How does that compare to the same risks with Ethereum Core devs?
- What about support for other blockchains instead of gAsp?
- What is Bitcoin fails or becomes co-opted?
- What happens if and when OP_RETURN data is auto-pruned?
- How are blockchain reorganizations (“reorgs”) handled by Aspire?
- How many GASP and ASP are there, and where are they?
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.
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.
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?
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?
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.
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?
What happens if and when OP_RETURN data is auto-pruned?
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.
We give a ton of credit to the Counterparty project. They indirectly inspired us to build Aspire which was expanded by using Counterparty technology.