Nano-node: Suggestion: alternative to POW that users can choose to use -> Burning NANO as fee

Created on 10 Sep 2020  路  2Comments  路  Source: nanocurrency/nano-node

I'm asking if the dev team che evaluate the possibility do add an alternative to POW that the user "can" choose to use instead of using POW (localy or remote)

The alternative is burning Nano, a very low amount, as fee.

Advantages:

  • Faster then waiting for POW.
  • Even more green.
  • Burning Nano means that the coin becomes even more rare/limited, and so its value is more likely to increase. (it is good for all holders)

I'm NOT saying to remove the POW as solution against the spam, I'm just saying that, if you add this feature, then the user will be able to choose which way to pay when he makes a transaction: POW or FEE.

Most helpful comment

We use PoW for two things: priority and correctness.

Priority: We process the highest priority/difficulty transactions first, this is the same as fee-to-miners or fee-by-burn.

Correctness: What is the minimum amount needed to create a valid transaction?

Where would you set the fee minimum burn fee for processing transactions? It's been suggested this is decided by votes of representatives, however, since the ledger is asynchronous, votes are not tied to blocks at a particular point in time, how do we validate blocks in the past for correctness? Since the fee may have shifted at some point in time and previous blocks that were invalid would become valid or visa-versa?

Disadvantages of burning fees is

  • The amount burned needs to occupy block space
  • Be signed in to the block by the sender
  • Requires the sender to sample the current network conditions, which may not be possible in a disconnected context
  • Balance erodes over time which is a confusing user experience

This problem is sidestepped by most coins by setting the transaction throughput absurdly below what technology would allow. The difficulty is how do you change the minimum-fee correctness property when considering the advancement of technology?

A difficulty with allowing both is with deadlocking consensus: if one version of a transaction has a high PoW fee, and one, conflicting transaction has a high burn fee, but nodes don't see both of these transactions, the network could have difficulty in progressing on which block to prioritize for processing.

Which specific problem are you trying to solve with fee-by-burn?

All 2 comments

We use PoW for two things: priority and correctness.

Priority: We process the highest priority/difficulty transactions first, this is the same as fee-to-miners or fee-by-burn.

Correctness: What is the minimum amount needed to create a valid transaction?

Where would you set the fee minimum burn fee for processing transactions? It's been suggested this is decided by votes of representatives, however, since the ledger is asynchronous, votes are not tied to blocks at a particular point in time, how do we validate blocks in the past for correctness? Since the fee may have shifted at some point in time and previous blocks that were invalid would become valid or visa-versa?

Disadvantages of burning fees is

  • The amount burned needs to occupy block space
  • Be signed in to the block by the sender
  • Requires the sender to sample the current network conditions, which may not be possible in a disconnected context
  • Balance erodes over time which is a confusing user experience

This problem is sidestepped by most coins by setting the transaction throughput absurdly below what technology would allow. The difficulty is how do you change the minimum-fee correctness property when considering the advancement of technology?

A difficulty with allowing both is with deadlocking consensus: if one version of a transaction has a high PoW fee, and one, conflicting transaction has a high burn fee, but nodes don't see both of these transactions, the network could have difficulty in progressing on which block to prioritize for processing.

Which specific problem are you trying to solve with fee-by-burn?

I guess that you have to use the same method as you are using to change the required POW on Nano, as you increased it lately.
So, maybe using the Ephoc blocks or something like them.

The amount burned needs to occupy block space

I think that you will need to find a way to use commitments:
https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11
https://twitter.com/ElectricCoinCo/status/1300828630470111232

Requires the sender to sample the current network conditions, which may not be possible in a disconnected context

So maybe this possibility isn't available in a disconnected context

Balance erodes over time which is a confusing user experience

This is an GUI issue I guess. The interface should be always asking the user what he prefer to do, and it should show the past choices, if he choose to use the POW or the FEE.
There should be also a default choice that the user can set or change lately.
POW should remaind the default choice on all wallets after the first installation.

This problem is sidestepped by most coins by setting the transaction throughput absurdly below what technology would allow. The difficulty is how do you change the minimum-fee correctness property when considering the advancement of technology?

As you said, with the "votes of representatives", so dinamicaly.

A difficulty with allowing both is with deadlocking consensus: if one version of a transaction has a high PoW fee, and one, conflicting transaction has a high burn fee, but nodes don't see both of these transactions, the network could have difficulty in progressing on which block to prioritize for processing.

I don't feel as expert as needed to answer this question, but I guess that the network can still give priority to a kind of tx if there are more conflicting, I would advise the tx with POW should have priority.

Which specific problem are you trying to solve with fee-by-burn?

  • Making tx even faster then now because there will be no wait for the POW.
  • Making the coins in the hands of the holders even more rare and so making it more likely (not certain) to increare value.
Was this page helpful?
0 / 5 - 0 ratings

Related issues

i3bitcoin picture i3bitcoin  路  4Comments

BitDesert picture BitDesert  路  6Comments

liuhailin picture liuhailin  路  5Comments

androm3da picture androm3da  路  3Comments

hskang9 picture hskang9  路  4Comments