Quote from: muf18 on June 05, 2017, 12:35:30 PM

Do you think they can implement in wallet burning coins function?

I'm not familar with the implementation but my educated guess is that they'd have to work explicitly to stop it.

The term burning is, in essence, a UI confection to help users establish a mental model of an abstract domain which can neither be directly inspected nor directly manipulated - the software acts a mediator in both cases, interpreting the domain to the user via analogies in order to avoid forcing the user to work with the underlying cryptography functions.

The analogy uses a model of addresses, accounts and transactions to represent the operation of cryptography functions and the resulting state changes. The analogy (or more properly in this case, metaphor) is a weak model and the originators failed to understand the full impact on the user of presenting such a weak model.

Simply sending coins to the burn address === burning the coins.

This can be done in any Slimcoin client that conforms to the comms protocols - be it by clicking a button on a GUI or submitting a JSON-RPC sendto request to a headless daemon's API, irrespective of whether the client is implemented in C++, Java, Javascript or LISP.

As Slimcoin users, we are observing a convention (and make no bones about it, it is just a convention) that the coins are then unrecoverable and can be subtracted from the total number of coins in circulation.

The software in the reference clients (those actually laying down blocks) treats such transactions as special and instead of calculating a PoS, it calculates a low diff PoW hash which is coded to have an increased probability of winning the block.

The address which is listed in the burn tx's txin (i.e the address which funded the burn tx) is credited with the reward if the PoB guess actually wins. The PoB factor for that tx is decremented with each try (win or lose) and so the burned coins are described as subject to decay (another metaphor of questionable merit).

Cheers

Graham