Add Burn Worker - Removes tokens from supply without refunding to pool about graphene HOT 8 CLOSED

Provable destruction of coins is actually a capability all cryptocurrencies have by default, that would actually take some work to remove. You can just create a "bricked" account by setting all its keys to 0000000000 or something.

This is more of a standardization / UI concern (what is the canonical way to "brick" an account, and how do we tell users that this account is definitely not going to spend any coins it may receive?) than something that requires writing blockchain level code (again, an account that provably can't spend coins is trivial to implement with existing primitives).

from graphene.

I think the easiest way is to simply include a "canonical bricked account" in the genesis block, and say if you want to create a burn worker, you simply point the worker to the canonical bricked account. This hopefully prevents all attack vectors that might exploit bugs in the brick detection code, because after genesis the bricked account ID can simply be hardcoded everywhere.

from graphene.

@theoreticalbts That's a pretty hacky solution. I think we'd be better to implement it as a first-class feature with proper tracking, rather than co-opting accounts and authorities to do it for us.

from graphene.

Why do you need a worker to burn? Is this just a terminology issue or does an actual shareholder approved worker person need to be voted in? Why? It seems like a great deal of overhead for some fixed address that routes to a bit bucket. I do agree however that tracking is an important consideration, just don't understand why a worker is necessary.

from graphene.

If there is no fee income, the hard cap on the inflow of new BTS from the reserve fund will gradually exponentially decay. There are two opportunities to narrow the flow below the hard cap: The delegates can use a proposal to narrow it to any amount below the hard cap, and the BTS holders can vote in reserve workers to further narrow it to any amount below the delegates' cap.

There is a debate:

• Some people like narrowing the flow as a solution, because it means the network can "save" dilution for a "rainy day" in the future.
• Some other people believe that narrowing the flow is not a satisfactory solution. Those people want a wide flow mostly directed into fireplace / bit bucket, to bring down the hard cap as fast as possible. They think that the potential for future dilution is bad, and want to "get rid" of as much potential dilution as fast as possible.

As a developer, I don't want to take either side in this debate. Instead I want to provide both sides the technical tools to allow the BTS holders the power to continuously vote on how wide/narrow the flow should be (below the hard cap) and where it should be directed.

from graphene.

Fascinating proposal @theoreticalbts. In other words, this is a dynamic "reserve account" in a way...but the account is owned by the shareholders/company?

from graphene.

Implemented in commit 548c760

from graphene.

Still needs tested.

from graphene.