#0002 Coinstake Transaction Split

[hrobeers]

To be discussed

[youngpascal]

RFC #0002

[nohea]

This proposal actually clarifies what is going on with a coinstake block, in terms of how much the minting reward is, by having 2 txs.
It will make multi-sig proof-of-stake minting possible, which is a huge win.

The only small disadvantage is there will be more small UTXOs (the stake reward tx), which are more difficult to mint again (unless moved to bigger pieces/kernels with a consolidating tx).

[hrobeers]

The protocol allows merging multiple outputs from the same address when only one of them mints claiming the total reward. So the small UTXO is a non-issue.

[d5000]

Support from my side (non-developer perspective, so I don't fully know the technical details), the rationale seams reasonable and I consider the cold-minting feature very important.

[Nagalim]

At first, I was hung up on the wasted coindays and the 'mess' created by what seems like an extra output. But ultimately, it really is not a whole lot for anyone, from big minter to little minter, due to the way it would wrap into the next mint. Instead, my issue here is with anonymity. By wrapping in a mint reward into another coinstake, you tie the identity of those two addresses together. Over time, this results in broadcasting public data outlining a connection between all addresses in your wallet. Perhaps it should only recycle UTXOs from the same address? Or make a new address for each reward? (this might be the correct answer, but it would probably bloat big minter's wallet files)

Other than moving the reward from coinstake to coinbase, this rfc also contains the minter's budget, which I don't think has any downsides.

[nohea]

Nagalim, I think the current minting behavior sends the outputs to the same address as the input. If this new coins take tx split protocol does the same (same address outputs for the 2 txs), the anonymity/non-anonymity should be the same as before.

[Nagalim]

Core protocol allows you to include whatever inputs and outputs you want to the coinstake, that's not my point. My point is that the convention of this rfc is to take an output of a coinbase and use it as an input to a coinstake in a different block. This will imply common ownership over both blocks, and therefore link the two staking addresses together as being part of the same wallet. Thereby anonymity is decreased.

[Nagalim]

The counter argument to this might be that once we have multisig minting the owner of the block reward and the minter might be different people, so the exact nature of the connection is obfuscated. Still, there is sharing of information here that seems undesirable to me. I wonder if we can improve the engineering somewhat to avoid giving out information about the addresses in someone's wallet every time they mint.

[sigmike]

Minters are able to include transaction data without paying the fee when they create a block, limited only by the blocksize

I don't think that is true. How can they do that?
The CoinStake transaction must include a fee. The fee is only reduced by the minimum fee (0.01). So there's already only 1 kB free.

[hrobeers]

sigmike is correct a minter get's only one kb free.

Perhaps it should only recycle UTXOs from the same address?

Coinstake merging is only allowed for inputs from the same address, that is the case today and this RFC does not intend to change that.

[sigmike]

Why isn't mquandalle's motivation listed in the RFC motivations? Is it just implicit?

As mquandalle said this RFC enables burning the coin age when a stakeholder mints on multiple chains (or just the wrong chain). Something similar is already implemented in Peercoin at node level to make the block disapear when the same stake is used on multiple chains. So the attacker only loses the compound interests of the reward he didn't get, and he is allowed to continue minting other blocks with this stake. With the coinstake split of this RFC it's possible to also burn the coin age by including its minting transaction in another block, so effectivly canceling one reward from the minter and delaying his next reward for 30 days.

The removal of the top block (the existing solution) may cause some implentation problems because we have to mark as invalid the perfectly valid best block. And there are situations where we must accept it again to avoid forks. This RFC may be seen as a solution to this implementation problem but it's not. We will still have to cancel the best block with the coinstake split, otherwise we cannot include the attacker's minting transaction in another block (it would already be in the main chain).

So the advantage of this change is to increase the punishment and make it much more enforceable.

Note that a similar punishment can be implemented at node level without a protocol change. The difference is on the enforcement of the punishment. With the protocol change it only takes 1 minter to enforce it, and with the node change it takes the majority of minters (and probably a large majority).

[Nagalim]

The more complete description of mquandalle's proposal is described in 'alternatives'. I just want to be sure that you realize that this RFC would not allow for mquandalle's proposal to be implemented, because the minter's budget is non-zero (meaning the transaction can be included as Coinstake transaction, but not as a normal transaction). Therefore, that increased punishment would not occur through this RFC, if I am understanding what you're saying correctly, so it is not an advantage of RFC-0002 unless the minter budget is reduced to 0, as described in the 'alternatives' section.

[sigmike]

Given the main benefit is the ability to implement RFC 3 (the tool compatibility is very minor), to me the acceptance of RFC 2 depends on the acceptance of RFC 3.