Cold storage minting proposal

[kactech]

New P2SH(let’s call it P2MINT for now) address that requires script to be ( coinstake ? 1 : 2)-of-2 multisig and in coinstake mode require all outputs’ pubKeyScripts to be P2MINT of that script.

Optionally limit outputs number and fee - stake destruction attack.

It’s mutation of sigmike’s solution - actually I don’t see benefits, just a note - even more, there is a con, we reveal spending pubkey, in case of ECC gets compromised there’s no protection while with sigmike’s solution funds are safe.

---

We can modify his script to something like this:

OP_COINSTAKE
OP_IF
   mintingPubKey
OP_ELSE
   OP_DUP
   OP_HASH160
   spendingPubkey.GetHash160()
   OP_EQUALVERIFY
OP_ENDIF
OP_CHECKSIG

scriptSig mint: mintingSig
scriptSig spend: spendingSig spendingPubKey

or

mintingPubkey
OP_CHECKSIGVERIFY
OP_COINSTAKE
OP_NOTIF
  OP_DUP
  OP_HASH160
  spendingPubkey.GetHash160()
  OP_EQUALVERIFY 
  OP_CHECKSIGVERIFY
OP_ENDIF
OP_TRUE

scriptSig mint: mintingSig scriptSig spend: spendingSig spendingPubKey mintingSig
/ requires both privkeys to spend /

Or we can make it w/o OP_COINSTAKE and make script verifiable by itself (w/o context knowledge)

OP_IF
   mintingPubkey
OP_ELSE
   OP_DUP
   OP_HASH160
   spendingPubkey.GetHash160()
   OP_EQUALVERIFY
OP_ENDIF
OP_CHECKSIG

scriptSig mint: mintingSig OP_TRUE scriptSig spend: spendingSig spendingPubKey OP_FALSE
This kind of modification is better then previous imo, we mark tx as invalid if scriptSig element is used in wrong context - we have to perform other checks outside script to perform more validation so no point for altering scrip core.
/ we need to check if OP_FALSE is used - malleability /

Another way is to define OP_COINSTAKE as constant, then

OP_DUP
OP_COINSTAKE
OP_EQUALS
OP_IF
   OP_DROP
   mintingPubkey
OP_ELSE
   OP_DUP
   OP_HASH160
   spendingPubkey.GetHash160()
   OP_EQUALVERIFY
OP_ENDIF
OP_CHECKSIG

scriptSig mint: mintingSig OP_COINSTAKE scriptSig spend: spendingSig spendingPubKey
My favorite

Using mintingPubkey instead of mintingPubkey.GetHash160() is rational.

[learnmore]

I’ve been pondering sigmike’s dual-key “minting address” proposal and the ensuing discussion in this thread. It appears that the foremost (and perhaps only significant) drawback to this and similar proposals is that it creates the possibility for “minting on another’s behalf.” This reduces security because it makes it rational to share one’s minting key with the entire world in the hopes that someone else will do the “labor” for you.

The larger philosophical question that arises is whether or not it is even possible to achieve complete security in the total absence of risk. The ultimate solution could likely require some fine balance between the danger and reward of producing POS blocks. The good news is that it seems that the necessary risk may not have to be very high.

I would like to raise he following possibility as a simple means of introducing some risk into the minting address proposals.

As I understand it, the “minting key” has to be able to spend to itself in the coinstake transaction. Why can’t this particular spending ability be made available at any time? In other words, if I obtain your “minting key” I can deliberately and repeatedly consume all of your coin-age and thereby prevent you from ever minting a block (and thus slightly improve the odds of minting my own blocks!)

This risk alone would seem to be a sufficient deterrent for sharing the minting key indiscriminately.

To address the concern about the creation of “minting pools,” I believe that ppcman has already raised a some very valid points about the lack of economic drivers for these to exist. If the entire reward can ONLY be paid to the minting address and the ONLY way to spend (to another address) from the minting address is with the private “spending key,” the risk/reward balance for pool operators is simply too unfavorable. The pools would really have no claim to any of the stakes they are minting and would be forced to either accept pre-payment (too much risk for the users) or trust in the honest “donations” of participants (too much risk for the pool operator.) Of course a purely malicious pool could attempt to offer >1% reward, but such a pool would by definition be untrustworthy and significantly wealthy holders would be no more likely to participate than contribute to helping a “Nigerian prince” retrieve his fortune. Am I being to naive?

Anyway, I confess that some discussions go right over over my head (my apologies to kac-), so please excuse me if this has been discussed before or if there are vital nuances I am missing.

Thanks for reading!

[kactech]

@learnmore

Why can’t this particular spending ability be made available at any time?

It would add some complexity to minting tx creation/validation but I think that it may worth it.
Example rule: for each input with COLD_SCRIPT[ ] require output on same position to have same COLD_SCRIPT and amount not less than input’s amount.

Actually I’m starting to like cold storage minting in this form.

[superppc]

[quote=“learnmore, post:82, topic:2336”]As I understand it, the “minting key” has to be able to spend to itself in the coinstake transaction. Why can’t this particular spending ability be made available at any time? In other words, if I obtain your “minting key” I can deliberately and repeatedly consume all of your coin-age and thereby prevent you from ever minting a block (and thus slightly improve the odds of minting my own blocks!)

This risk alone would seem to be a sufficient deterrent for sharing the minting key indiscriminately.

To address the concern about the creation of “minting pools,” I believe that ppcman has already raised a some very valid points about the lack of economic drivers for these to exist. If the entire reward can ONLY be paid to the minting address and the ONLY way to spend (to another address) from the minting address is with the private “spending key,” the risk/reward balance for pool operators is simply too unfavorable.[/quote]

risk should be higher than just 0% return (losing minted coins), otherwise ppl doing cold storage may just use a pool (rather than make 0% ) and hope for the best - nothing to lose

i guess minting pools won’t be hard to setup, out of 100 ppl u can’t expect all of them to act rational. you just need 1 pool to disrupt the ecosystem

[learnmore]

I do agree that introducing the possibility of negative returns would even further discourage pooled minting on the part of the pool users. From the pool owners’ perspective, however, I’m still having trouble seeing any incentives to sustain massive pools when they have no ability to reap any direct (licit) gains from it. The question is how much “fabricated” discouragement is actually needed to prevent realistic threats against the network. Maybe loss of coin-age isn’t enough threat, but I’m afraid that many people will be turned off of Peercoin entirely if the minting “rules” appear too complicated or if even “cold-locked” minting addresses are susceptible to principal losses. I really hope the final minting solution keeps Peercoin’s simplicity theme intact!

[superppc]

assumption is most ppl are rational: u can discourage most ppl but not all ppl. so we have to focus on discouraging most ppl not to use pools rather than all ppl not to make pools. few ppl may use pools but it won’t matter if most don’t.

[kactech]

Example rule: for each input with COLD_SCRIPT require output on same position to have same COLD_SCRIPT and amount not less than X% of input’s amount.

To discuss: X increases with coinage, f.e. 30 days - 95%, 90 days 98%, 180 days 99%
Motivation: disincentivize pooled minting (low variance and compound), possible loss decreases over time but same time chance to find block in solo increases.

Covering all scenarios is impossible - f.e. attacker can use FB’s escrow to cover possible losses thus leveraging his attacking stake, we expect Peercoin holders to be rational.
EDIT: debunked by superppc, owner can ~steal his coins and claim escrow funds

[superppc]

@kac-

Example rule: for each input with COLD_SCRIPT require output on same position to have same COLD_SCRIPT and amount not less than X% of input’s amount.

pls explain in non-dev terms so also non-dev can understand and add value

[superppc]

@kac-

Covering all scenarios is impossible - f.e. attacker can use FB’s escrow to cover possible losses thus leveraging his attacking stake, we expect Peercoin holders to be rational.

could backfire, owner could then transfer coins and claim they were stolen by pool and get escrow money

[kactech]

@superppc

[quote=“kac-, post:87, topic:2336”]Example rule: for each input with COLD_SCRIPT require output on same position to have same COLD_SCRIPT and amount not less than X% of input’s amount.

pls explain in non-dev terms so also non-dev can understand and add value[/quote]
This rule allows use cold locked stake with other stake - stakes w/ different addresses/keys - in case minter doesn’t want his whole stake to be visible at one address [important] (or he has coinage in cold wallet he wants to use [marginal but preserves current liberty in coinage usage] ) but he wants to still be able to use all of his coindays in one minting TX to take interest and f.e. move his coins to exchange.
Side effect is that it encourage to use pools - no/low variance(~payout each 30 days) and compound interest.
Increasing X with time = decreasing with time possible loss (minting key compromised, pool usage).

@superppc

[quote=“kac-, post:87, topic:2336”]Covering all scenarios is impossible - f.e. attacker can use FB’s escrow to cover possible losses thus leveraging his attacking stake, we expect Peercoin holders to be rational.

could backfire, owner could then transfer coins and claim they were stolen by pool and get escrow money[/quote]
Right

[RobertLloyd]

@river333

2) A proposal to have a minting key but with a twist that removes the incentive for centralization. If your minting key was compromised, you wouldn’t just lose the minted coins but also a small percentage of the actual coins from cold storage. The idea being that if the risk was slightly higher, for example 1-5% of staked coins, then this would discourage centralization as it wouldn’t be worth the risk giving coins to a minting service. In this case, the worst case scenario of a centralized provider stealing your coins would be the minted coins plus a small bit of staked coins, as opposed to just losing the minted coins.

I wonder whether this can undermine the future marketing of Peercoin. To get people to mint, they have to be assured their coins are safe. This is achieved by transmitting a single, clear message - coins are safe with cold minting. If we allow a few percent to be risked (even though for the best of reasons) it means we cannot broadcast that simple message - we instead have to qualify it, and that may muddy the water and put people off

[superppc]

@RobertLloyd

I wonder whether this can undermine the future marketing of Peercoin. To get people to mint, they have to be assured their coins are safe. This is achieved by transmitting a single, clear message - coins are safe with cold minting. If we allow a few percent to be risked (even though for the best of reasons) it means we cannot broadcast that simple message - we instead have to qualify it, and that may muddy the water and put people off

imo it’s the price to pay to avoid ppl saying “it’ centralized”

[Chronos]

@river333

2) A proposal to have a minting key but with a twist that removes the incentive for centralization. If your minting key was compromised, you wouldn’t just lose the minted coins but also a small percentage of the actual coins from cold storage. The idea being that if the risk was slightly higher, for example 1-5% of staked coins, then this would discourage centralization as it wouldn’t be worth the risk giving coins to a minting service. In this case, the worst case scenario of a centralized provider stealing your coins would be the minted coins plus a small bit of staked coins, as opposed to just losing the minted coins.

This is a clever idea. But, like others have said, it makes things complicated. Also, for some people, it might stop them from cold minting at all, because even 1% is too much to risk (it’s an entire year of minting). Perhaps 0.1% is enough to prevent pool formation, or perhaps not.

[superppc]

@Chronos

This is a clever idea. But, like others have said, it makes things complicated. Also, for some people, it might stop them from cold minting at all, because even 1% is too much to risk (it’s an entire year of minting). Perhaps 0.1% is enough to prevent pool formation, or perhaps not.

i think the point is that not everyone is supposed to mint, only ppl that are computer-savvy enough to do it on their own hardware. that’s why it’s good that minting is only 1% so ppl that lack the technical skills will just keep coins in cold storage and are not at too much disadvantage. just like in high inflation countries you must invest, in low inflation countries u can choose if to invest or not which allows for only the most savvy to invest. i think someone with an average understanding of computer security will mint for a 1% risk of loss. a total newbie running windows xp won’t, but that’s ok too.

[whifmoi]

I’m one of the owners of “big stake”.

I prefer to have a dedicated mining address, an address where minted coins accumulates.

My stake is distributed over many addresses, that I’m not on “best lists”. I remind on a Sunnys comment to distribute large stake over several addresses.

I honor the activity on better mining security. I will never sell in an uncoordinated manner, but if my coins get stolen, exactly this could happen. Remind, in my case an attacker had to steal from many different addresses.

I made a proposal long before:

Idea: "Proof of Confidence" - PoS variant with locked coins for value stability

This could also be an incentive for minters, keeping their wallet online. And the higher the incentive, the more stakers will mint. Don’t take the numbers in % literally. It could start with 0.25% if all minters are active, we had to discuss this. There was also a discussion, to nullify the reward from the minters own stake, not to favor wales.

As an admin I know what I’m doing. A dedicated linux VM connected to the internet via VPN, no incoming connections possible. But I never feel 100% sure.

[Cybnate]

I like your proposal of providing the destroyed coinage to the minter of that block. That way you can still guarantee 1% reward and a chance on a bonus while keeping ~1% inflation on average. It is a relatively cheap way to increase the rewards and motivate small and medium stakeholders to mint. But given the current distribution it needs to be combined with incentives for large stakeholders to be valuable.

[hZti]

In my opinion the main problem is that 1% is so less for such volatile currency that most people trade a little bit and get way more coins with that or just don’t mint.

[whifmoi]

@hZti

In my opinion the main problem is that 1% is so less for such volatile currency that most people trade a little bit and get way more coins with that or just don’t mint.

Yes, my suggestion should solve this, giving more incentive on less minters. And: Cryptos are not Fiat. So 1% a year is much for a deflationary currency. The 1% should primarily replace lost fees and lost coins, thus making the coin less deflationary and more stable.

[kactech]

@hZti

In my opinion the main problem is that 1% is so less for such volatile currency that most people trade a little bit and get way more coins with that or just don’t mint.

Trading is an opposite to safe storage, may be seen as zero-sum(or even negative-sum w/ fees) game.
1% may be treated as storage-exchange mediums swap cost coverage.

[Chronos]

This is a difficult problem. A minting key needs to be safe/exposable enough that a user feels safe keeping it in a hot wallet, but not so safe/exposable that a user feels safe giving it to a minting pool.

Perhaps no perfect solution exists! What approach is Peershares taking?