dear Igno, >> Should we give up on the possibility to burn coins, and give up on >> incentivizing small blocks, because of the perceived complexity of >> a subtraction? > > There's a little more complexity involved. First, you have to think about > fast-synced pruned nodes. They have to know about past burn somehow. All the > information they have is headers, the UTXO set and kernels. So putting the > burn in any of those places would likely work. And hopfeully we won't have to > worry about SPV for some time. But still, should we commit to total burn in > headers?
Yes, cumulative burn should definitely be a header field in my proposal. And possibly block burn as well (the difference from the previous block's cum.burn), if we feel like being generous with header fields. > Now, people. We have a constant emission that people already have > difficulties wrapping their head around, strangely enough. If the answer to > "what's the total emission at this point in time" requires either checking > all kernels It only requires checking current height and one header field. And then we have a much more precise answer than bitcoin, which has all sorts of ways in which to burn coins. Some are used as one-way pegs into other currencies. Perhaps one day people will do such one-way pegs on Grin as well. > or something more evasive like "depends on how full blocks are", that > explanation is going to get a lot worse. Emission is a fairly fundamental > parameter, being able to just say one per second or 60 times the number of > block is a remarkable average that we shouldn't just brush off. I would still claim a 1Grin/sec emission. That answer can be a little less precise than if the question is "what's the supply at this time?". > Going back to the data, by adding burn to kernels you're trading off 8 bytes > for every transaction against maybe one average unprunable output per block > (we could perhaps do less by setting a minima under which burn isn't > necessary). I much rather have every one able to burn rather than only the miner. It allows more flexibility in miner compensation, one-way pegs, and perhaps other use cases we haven't thought of yet. It makes the design more regular in that the coinbase tx looks less distinguished. 8 bytes per kernel is a smallish price to pay for that. > I'm also wary of having kernels sign more data. Who knows, maybe we'll figure > out signature aggregation at some point and the more we can aggregate the > better. We already sign fees, and burn is entirely similar. Whatever method you have to aggregate kernels with fees should also work for burns. > Also, by having burn and fees in every transaction, you complicate > transaction ordering for miners. It becomes a 2-variables problem which I > don't really even want to think about right now. This complication is entirely outside the grin codebase. Much like the complications I introduced in my cuckoo solver to make it run faster. We really shouldn't worry about what miners will do to maximize their profit. regards, -John -- Mailing list: https://launchpad.net/~mimblewimble Post to : mimblewimble@lists.launchpad.net Unsubscribe : https://launchpad.net/~mimblewimble More help : https://help.launchpad.net/ListHelp
