Replace PoW with useless tokens

Protocol Design
#1

[Note: I have modified / improved the suggestion in subsequent comments, scroll down to see my later ideas]

PoW is useless and wastes energy. Let's replace it with useless tokens.

This is not a joke.

You want Nano to be feeless at any cost. Alright, got it.

You want users at countries where 1 cent is not considered disposable change to be able to use the service without worrying about fees. Got it.

Many of these users only have mobile phones (and probably not very fast ones) that wouldn't be able to compute PoW. So your solution is to compute it and gift it to them (I'll ignore for now that this kind of service is highly susceptible to abuse).

So instead of donating useless computing power and electricity (which costs money and causes carbon emissions), why not donate useless tokens instead?

Design tokens that can't be used for anything other than as a burnable "gas" for performing a transaction. One token = one transaction.

Now you might think: Everything has value. These tokens would be traded eventually.

I'm not a finance person (more of a computer science person), but I don't think anything is impossible. Let's try to shift the effort for a minute from things like memory hard PoW and precomputed attacks to considering the idea of a token that is useless by definition - the only thing that it can do is be burned to perform a transaction.

This should be the worst possible token for investors: infinite supply, arbitrary price decided by software, not tradable anywhere, could lose its entire value at any second. As useless as tokens in a theme park that's in the process of filing for bankruptcy.

This shouldn't be that hard?

Here are some ideas: the token will be materialized by burning a small amount of Nanos to some predefined bogus account. The token will have versions like v1, v2, v3 etc. that would increment with software upgrades. Once the version is upgraded, all the tokens of versions one before the current one would become completely useless (for example upgrade form v2 -> v3 causes v1 to become useless). Tokens cannot be traded between versions. This means the tokens would have to be bought only for short-term use.

I haven't spent a lot of time in considering the specifics of this kind of idea, but I think people with different backgrounds than mine (like finance and economics) could easily come up with even better solutions. As a technical person I understand the development cost of implementing a secondary "balance" (albeit it would only be a simple integer, 4 bytes suffice) but I want to put that aside for now because I believe the effort would certainly be worth it if it proves to be effective.

#2

Isn't this equivalent to fees or proof of burn?

#3

It is close, but not exactly. The idea is to try to somehow design a token "embodies" the same qualities as PoW and can be gifted between accounts.

It can only be used for one purpose (gas for a transaction), maybe even only for the particular account that it is issued for (so it is not possible to sell it at all).

I guess the primary pattern would be that it would be gifted from a service similar to the current distributed PoW service. But instead of donating computing power, volunteers would donate funds that would be be burned in exchange for tokens that can only be used by a particular account for a limited amount of time.

Now it may seem expensive to "burn" money, but the amounts would be so little and possible comparable to how much it currently costs to pay for the PoW electricity.

Something along that lines. I'm still pretty vague about this. I'll need to consider this more.

#4

Alright, maybe something like this:

User A wants to buy some Gas tokens for user B.

User A issues a "send" transaction to user B but instead of sending Nanos they set a Boolean value in the block that causes the funds to convert to Gas tokens instead.

User B accepts the transaction and their Gas token balance is now increased (no change to their main balance).

(and if user C wants to buy Gas tokens for themselves they send a similar transaction, but to themselves)

Something like that.

#5

I'll try to rephrase the concept in a clearer manner:

  • Gas tokens are tokens that are designed such that they will always be "free" - meaning that honest users would never be required to purchase them themselves and will always be able to get them at no cost from a fountain (maintained by donors who are incentivized to contribute these funds to increase the value and user base of the currency).

  • Gas tokens cannot be transferred between accounts. They can only be bought (either by the account owner or by a secondary account). New accounts require Gas tokens to be bought for them using real money (I've demonstrated an implementation approach for that in the previous comment).

  • The maximum amount of Gas tokens may be limited for each account (they can't be hoarded).

  • The price of Gas tokens can be literally changed by randomness! and can also vary by parameters like stake, account history, transaction rate of the account, overall network congestion etc.

  • Gas tokens can vanish without any warning! Literally by random chance!

The idea is to design these tokens to be so terrible to buy and hold so that individual users would not be incentivized to purchase them. However, because of those same "broken" properties they can be made so cheap that fountains wouldn't require a fortune to be maintained. The only ones who would be incentivized to buy such a broken asset would be the donors who understand that these same broken qualities guarantee the integrity of the network as a whole as well as maintaining the low price.

It is still possible that attackers would be willing to buy them despite all of these "guards".

The question is, how low can we go? what would be the cheapest price that can still deter attackers?

  • 1 cent per token means 100$ per 10,000 spam transactions (not a serious attack)
  • 0.1 cent per token means 100$ per 100,000 spam transactions (more serious attack)
  • 0.01 cent per token means 100$ per 1,000,000 spam transactions (quite serious attack)
  • etc.

(of course the token can become several times more expensive for accounts with a history of high-transaction counts, low stake etc. I'm giving these numbers as rough baselines to consider)

Another way to analyze this is to look at other networks with super-cheap transaction fees and see how many attacks they actually get (assuming they have an active userbase).

#6

There is delegated PoW. We implemented Nano in the Kaiak wallet for KaiOS. You can consider these phones to be low end. It works fine and is as fast as an Android or iOS wallet. So, I don't see the problem here.

1 Like
#7

Iteration 3: prepaid token contracts

I've spent many hours working on this and I think I'm making some progress:

The previous approach had the price of each token being determined at the time they are bought. The problem with this is that attackers could still manage to take advantage of this by buying the tokens very cheaply, right before the price rises due to the attack.

The obvious solution would be to have transactions consume variable amount of tokens (including fractional amounts) that are determined at the time of the transaction, but I think I have a better idea that will also be very useful for the fountains:

Instead of buying tokens at the current token price, the fountains will issue a contract where they pay x amount of Nanos for each of the n tokens that are issued.

For example, the fountain will issue a contract where they provide credit for 5 tokens at a maximum price of 0.1 cents each (or equivalent Nanos). The contract doesn't expire, but will have a minimum token count (5 seems like a reasonable number) to prevent the network wasting resources at unnecessary "buy tokens" transactions.

The client will accept this contract, but will only be able to make use of it if the token price is below 0.1 cent.

If the network is congested, they will have to either wait until it clears or load another contract instead (for simplicity, there can only be one gas token contract at a time). The tokens that are thrown away are not refunded (it is technically possible to trace back and refund to the original issuer but it would take too many resources, and would require spending tokens by itself).

This may seem like a waste but the fountains can be abused in many other ways. Also, the fountain can look at the account's ledger and decide to ban it from receiving further tokens.

Now attackers who want to flood the network would have to "guess" the future token price before they start the attack. Most likely this would be a very effective measure so attacks will be reduced considerably (and thus the token price can remain very low).

#8

This sounds like fees with a lot of extra steps.

1 Like
#9

These are technically not fees since they are not payed to anyone. There are not much extra steps. It may only seem like it since I've developed it quite a bit (at least 20 hours of work were put to this). The "contract" I describe is only 5-6 bytes added to the block (current balance of tokens [1-2 bytes] and price of each token [4 bytes]).

It is derived from the idea of proof-of-burn, but builds a more sophisticated scheme on top of it that is potentially very effective against attacks, as well as designed to drive the token price to a very low value.

The tokens represent burning of a Nanos, however they allow the burning to be also performed by a secondary account. This allows the tokens to be fully subsidized by an external entity like a fountain (the design goal is that virtually everyone will use the fountain to obtain tokens - thus the tokens would be effectively free).

The base price of the token is zero. The price only rises if the network activity crosses some threshold (as well as individual aspects relating to the particular account). Every transaction requires spending a token (including buying tokens). The price of the token is determined by an algorithm. The user has to buy the token for at least the current price to perform a transaction. Tokens bought at lower price cause the transaction to be rejected. Tokens bought at higher price do not give any advantage (there is no prioritization based on the price paid - this is deliberate to drive the price down).

Users, as well as the fountains, have to pre-pay for at least 5 tokens at a set price. This is a very deliberate design that is meant to reduce network processing and as well as to drive the price down. Because users have to buy the tokens beforehand, in bulk, they are more likely to wait for the price to go down than buy another whole set, and waste the remaining tokens they bought, in case the price goes above it. The same is true for wasting tokens provided by a fountain (which may cause the user to be banned).

The fountain will buy n tokens at a set price (what I describe as a "contract"). If 90% of the users rely on the fountain exclusively, then when the price goes higher than the price the fountain pays, the users will effectively "stand in line", the fountain would be now be regulating the network using this simple measure.

This design is meant to be very strong at preventing attacks. Possibly much stronger than proof-of-work. The requirement to pre-pay for the tokens means that the attacker must "predict" the future price (the price during the attack itself) to carry out an effective concentrated attack. The attacker also has to buy 5 times the amount of tokens they may need for a multi-account attack. These tokens are not refundable.

A more sophisticated attacker may try to use the "buy tokens" transaction itself as the attack vector, but that transaction also requires already having a usable token, or deducting one of the tokens bought. In any case they will need to use some estimate of the future price and a lot of money may be wasted. Also, the, "emergency" price can also be randomized which may make it even harder (even if they manage to predict the average "emergency" price half of their transactions would be rejected).

#10

The point being here: If you introduce some kind of incentive structure or token for payment or whatever, you are going to get some kind of fee. People can sell these kind of tokens or however you want to call them. And that is the problem. PoW is something everyone is able to do. Dynamic PoW isn't perfect, true. That is why we should think about something to support it. But introducing some kind of incentive is a bad idea.

#11

The token is not transferrable between accounts. Cannot be refunded. Cannot be incremented.

Also, maybe "token" wasn't the right word, it acts more like a "point", "credit" or "voucher".

I have made 3 different variants of the idea in this thread. I apologize if it creates confusion. I don't think I have done a good job at summarizing it so far since I developed the idea as I went, throughout multiple comments.

The base reasoning behind this suggestion is that proof-of-work, in sense, acts a lot like an "asset" or some sort of "token". It has various qualities that may be possible to be captured using the concept of proof-of-burn.

Users of the network in countries without access to banking (and very low purchasing power) most likely would also have a very low-cost phone that wouldn't be able to run proof-of-work at a reasonable time (and probably no PC or laptop). Nano's current solution is that they rely on a distributed network of volunteers who donate computing power and "gift" them the PoW solution.

In a sense, that is not that different from a fountain. I'm trying to explore the idea that instead of donating computing power they could donate funds to a fountain, that would be burnt and converted to "tokens" (aka "points" / "credits"). I describe these "tokens" as useless since they cannot be, transferred, sold or refunded.

The goal is to see if it is possible to disincentivise users to pay for them using their own funds, and instead get them exclusively from fountains (with some exceptions for special "emergency" cases). Also I've shown this system can be made more resilient to attacks than PoW (including multi-account attacks).

Nano Forum | Terms of Use | Privacy Policy | About | FAQ