Alternative to PoW/PoS/PoB - Proof of Deposit

[XertroV]

It occurred to me that Proof of X realistically only requires a sacrifice that anyone can make (or at least a large enough subset of users). For example, PoW uses energy, PoS uses coindays, and PoB uses coins.

There's a fourth option I'll call Proof of Deposit. Basically you just lock your coins up for some particular length of time (like 20 weeks) and you're paid a bit for it. Technically this is similar to PoS/PoB (all three have almost the same economic implications) but provides more information to users at the expense of impulsive (but costly) attacks.

PoS destroys coindays, PoB destroys coins, PoD removes control of disbursement for some time.
Economically in all three cases coins are removed from the supply for some time and then reintroduced at a later time. In the interim all other coins should appreciate slightly in value. After that time has elapsed the miner is given a little reward and her coins back as thanks for making everyone a little wealthier for a bit.

The easiest way to manage this (from my perspective) would be to require each coinbase tx to have the following:

Code:

Inputs: X coins where X is the difficulty parameter, signed
Outputs: 1. Block reward to arbitrary key
2. Output leading back to owner for X after some time.

scriptPubKey for 2 might look like:
_OUTHEIGHT _INHEIGHT <depositTimeInBlocks> _ADD _GREATERTHAN _IF
     (back to owner)
_ELSE _RETURN _ENDIF

OP_OUTHEIGHT pushes the height of the tx spending the output to the stack (IE most recent block, for all intents and purposes)
OP_INHEIGHT pushes the height of the block the tx was included in to the stack

I think it's important to stress that PoS/PoB/PoD have the same economic implications but different psychological implications.

For a blockchain to internally fuel itself there must be some internal resource which is sacrificed. Ultimately the only internal resources we have to sacrifice are the coins themselves, so it should come as no surprise that PoS/PoB/PoD look the same from a macroscopic perspective.

[1715210969]

1715210969

[1715210969]

1715210969

[1715210969]

1715210969

[1715210969]

1715210969

[1715210969]

1715210969

[maaku]

How is HEIGHT different from INHEIGHT?

(both don't exist and would be hard-fork changes)

[XertroV]

How is HEIGHT different from INHEIGHT?

(both don't exist and would be hard-fork changes)

INHEIGHT is the block the tx was included in (say #4). At that point in time HEIGHT and INHEIGHT both return 4.
100 blocks later HEIGHT will return 104 and INHEIGHT will return 4.

Introducing a new Proof of X system would require a hardfork to Bitcoin anyway - and is a prohibited change. I'm more suggesting this for the theoretical implications.

[maaku]

But script execution only occurs when a new block is created/validated, and at that point in time the "current best block" is the block including the transaction. Are you making a distinction between input height vs output height?

And no, hard forks are not required for proof-of-x systems to be implemented in bitcoin. That's just required in the braindead way they've been handled in alts.

[XertroV]

But script execution only occurs when a new block is created/validated, and at that point in time the "current best block" is the block including the transaction. Are you making a distinction between input height vs output height?

Yes, that's probably a better way to do it. INHEIGHT and OUTHEIGHT

My understanding was that a tx is checked to be not-malformed when included in a block but the scriptPubKey is only evaluated when the tx is spent. We can send to arbitrary P2SH addresses so I don't see why the scriptPubKey would be an issue.

And no, hard forks are not required for proof-of-x systems to be implemented in bitcoin. That's just required in the braindead way they've been handled in alts.

The only way I could think of adding PoX into Bitcoin without a hardfork is to keep PoW as it is and add PoX as an extra constraint which is stored in the coinbase scriptsig perhaps. If the majority of clients are new then the blockchain will be validated according to these new rules but the small proportion of older clients will still validate PoW as usual. However, if the difficulty decreases due to the extra constraints then there's the potential for an attack on old clients by ignoring the new constraint and just mining PoW.

That said, I don't think that is an elegant way to do it. Have there been other suggestions?

[behindtext]

have you considered the PoJ system: proof of job?

everyone has to photocopy their pay stubs and send it to a property management company so they can obtain PoH (proof of house) tokens.

[maaku]

The only way I could think of adding PoX into Bitcoin without a hardfork is to keep PoW as it is and add PoX as an extra constraint which is stored in the coinbase scriptsig perhaps. If the majority of clients are new then the blockchain will be validated according to these new rules but the small proportion of older clients will still validate PoW as usual. However, if the difficulty decreases due to the extra constraints then there's the potential for an attack on old clients by ignoring the new constraint and just mining PoW.

That said, I don't think that is an elegant way to do it. Have there been other suggestions?

Here's a simple way you can make it into a soft-fork change: compress HEIGHT, GREATERTHAN and VERIFY into a single opcode that doesn't have to modify the stack. Then you can re-purpose one of the NOP opcodes.

Proof-of-burn as usually described doesn't change bitcoin's validation rules, at all. I'm mostly aware of its usage in higher level protocols such as identity protocols which simply reference the burnt coins and maybe some data attached to them in the OP_RETURN output.

Proof-of-stake as originally described didn't require any protocol changes either. It is simply a mechanism for counting votes for or against a proposition (such as checkpointing a block) by weighting those votes according to the coins the pubkey signing the vote is protecting. This is a higher level protocol which can affect the client / wallet operation, but not the actual validation rules so no fork is required.

If you integrate proof-of-x in with mining, then yes hard forks are required. But why do that? It ends up weakening security instead of strengthening it.

[eb3full]

While we're on the topic of prohibited changes, we should abandon the entire idea of prohibited changes, because they're all 1) arbitrary, 2) disputed, 3) completely out of the control of the developers.

Even if all Bitcoin users decide to adopt any of these changes, the resulting cryptocurrency can no longer be considered "Bitcoin" because it has diverged too much from the original design.

^ who wrote this?

Prohibited changes should be anything which isn't expected to receive widespread acceptance among users and miners, like changing the monetary base or controlled currency supply rate.

It's not outside the realm of possibility to adjust the block target to 2.5 minutes, and make the block subsidy 1/4 as large to compensate. I would still call it bitcoin if everyone else did. I'm not recommending this change, I'm Just Saying.

[maaku]

We're not on the topic of prohibited changes. Please create a new thread if you want to discuss that.

[XertroV]

Here's a simple way you can make it into a soft-fork change: compress HEIGHT, GREATERTHAN and VERIFY into a single opcode that doesn't have to modify the stack. Then you can re-purpose one of the NOP opcodes.

Proof-of-burn as usually described doesn't change bitcoin's validation rules, at all. I'm mostly aware of its usage in higher level protocols such as identity protocols which simply reference the burnt coins and maybe some data attached to them in the OP_RETURN output.

Proof-of-stake as originally described didn't require any protocol changes either. It is simply a mechanism for counting votes for or against a proposition (such as checkpointing a block) by weighting those votes according to the coins the pubkey signing the vote is protecting. This is a higher level protocol which can affect the client / wallet operation, but not the actual validation rules so no fork is required.

If you integrate proof-of-x in with mining, then yes hard forks are required. But why do that? It ends up weakening security instead of strengthening it.

Ahh, I see what you mean. I was originally exclusively talking about mining new blocks - essentially chasing the idea of a blockchain without a power-hungry mining backend.

Proof of burn probably translates to a 'cost' the best, so for identity extensions it makes sense (either that or use PoW). PoS or PoD probably are more suited to 'renting' type situations where you need to show intent for some period but want your funds to remain exclusively yours. (Or voting as you mention).

Instead of repurposing an opcode you could write a meta-network (like Mastercoin) that searches for commands after OP_RETURNs and if it finds a network identifier proceeds to interpret the trailing data by some other ruleset. Either way the argument stands.

Why? Because I want to see what happens. If it's insecure then an attack should be possible, but there are some conditions where an attack is much harder, so there are different properties to each form of currency, and neither is universally inferior to the other.