> A transaction which spends all three at once to a single 1 BTC bc1apple would comply, and yet turning 2 BTC to fees is probably not what you intended to permit.

Well that's a pretty good point I haven't thought of. Perhaps the answer is to allow putting a cap on the fee in the covenant (and rely on cpfp in cases where that fee doesn't end up being sufficient)? But the use case I'm interested in does not involve limiting the amount of coin that can be sent in a transaction (in fact that seems like somewhat of a useless covenant, since whoever has access can simply send multiple transactions to grab most of the balance (leaving whatever remainder doesn't divide equally).

> The single use case absolutely requires no malleability, and that ends up creating a lot of limitations

I agree, and the limitations built into this opcode are what I'm concerned about as well.

> I think it would be worth the time to do it right.

I agree. I do think that the ability to put limitations on how utxos can be spent is incredibly important. The main use case I'm interested in is "bitcoin vaults" that could make it possible to create wallets that are substantially more secure from theft and at the same time substantially more secure. Doing this in a user-friendly way requires allowing users to spend any amount contained within a wallet, but with limitations (for example, that all funds must be sent to a particular address that has a number of spend-paths with different timelocks).

I would agree that op_ctv as it stands is not general enough and has some loose ends and redundant options.

I'm surprised there isn't already a discussion here about op_ctv. This is BIP 119: https://github.com/bitcoin/bips/blob/0042dec548f8c819df7ea48fdeec78af21974384/bip-0119.mediawiki

I'd like to specifically talk about the requirement of specifying an exact number of inputs that are required to spend the output. I understand the necessity of specifying exact inputs, but I don't understand the use case for specifying a number of inputs without specifying the exact inputs to spend. In addition, the BIP recognizes that committing to the sequences hash makes committing to a number of inputs "strictly redundant", but says doing so makes it easier to construct StandardTemplateHashes from the script.

Can anyone expand on what is said in the "Rationale: Committing to the number of inputs" section in the BIP?

The use case I'm concerned with is creating a timelocked cold wallet where arbitrary funds can be spent, but within some time-period the transaction can be reversed (for example, by a different higher priority key or by a multisig wallet with more keys than were used by the transaction being reversed). Requiring that op_ctv specify a specific number of inputs makes that use-case not generally possible or at best not efficient, since the wallet can contain many inputs, and in order to spend, you'd have to either have to spend each input one at a time, or you would have to have a large script that specifies optional op_ctv spends for every possible number of inputs you expect the wallet to have, which is obviously a bit of a pain and can go wrong if the wallet ends up having more inputs than you built the script for.

Why not make specifying the number of inputs an optional thing so that some people can use it when its necessary and some can omit it when its not?

How would other nodes detect that they're intentionally not approving blocks in order to blacklist them? Isn't anyone allowed to not approve blocks if they don't want to?


But isn't only including your block as the only approved block the best way of gaining an advantage? This is known as the "bullet-voting" problem in approval voting, ranked voting, and range voting circles. https://en.wikipedia.org/wiki/Bullet_voting . While in normal voting, this shouldn't usually be much of a problem, it seems like in Proof-of-Approval there is a big incentive to bullet vote.

@tromp - Ok, after more thinking, you're right. Long-range revisions still need to be mitigated somehow, so how about this: Get rid of the commonProportion piece, start with pure PoW and after a significant amount of coins have been distributed (say 50% of the maximum or something like that), then introduce the PoS parts of the protocol. Also use hardcoded checkpoints in software to block long-range revisions. What dyou think? If this protocol were used in Bitcoin, we could basically just skip right into it, since Bitcoin has long since passed that point.

@tromp - You know, that's a good point. I guess the ordering doesn't guarantee it mathematically, but the work put into building blocks practically guarantees it. Just like how it would be incredibly expensive to build a longer blockchain than bitcoin's blockchain, it would be very expensive to create any long range revision of a PoTO chain. If you're talking about a node comparing a set of shot-range revisions (a few blocks) the commonProportion won't be different enough to matter. If you're talking about long-range revisions, you're talking about incredibly expensive attacks, and I talk about ways to mitigate that in the section "Mitigating Long-range Revision Attacks". Is there a scenario you think might cause trouble for a system using this protocol as is?

@aleksej - Mining is not a practical way for anyone in "remote places without a proper banking infrastructure" to acquire coin. In fact, its not a practical way for most people to acquire coin beyond a certain point. You have to have good network connectivity in addition to a lot investment in mining hardware to mine, and people in remote places aren't likely to have that. If the people in a certain aren't able to earn or buy cryptocurrency, the ability to mine isn't going to solve the problems that causes. And if their government is preventing them from receiving bitcoin, what's stopping their government from preventing them from sending bitcoin? Earning coin by mining is useless unless you can spend it. So I have to disagree that the ability to mine the coin without having coin is very useful beyond an initial distribution phase (eg the phase bitcoin is largely out of at this point).

@Aleksej - I wouldn't call requiring coin ownership a "permission" since anyone should be able to acquire and own some coin, otherwise your coin fails as an economic mechanism. Requiring that miners compete on coin ownership increases the cost of attacking the system potentially by an order of magnitude or more. But what is the importance of the "permissionlessness" you're talking about? Why is that a desirable property? Perhaps there are other ways to achieve the goals you have in mind. If your concern is about centralization in the initial coin distribution, its certainly an easy change to limit coinbase rewards only to miners, and to not implement the hash-stake extension until there's an established market for acquiring coin. I mention most of that in the section on "initial centralization and long-term centralization".

@AdSkull - Read the protocol and you'll find out : ) That's why I wrote it.


@ tromp - Its not a total order because of the "commonProportion" term. Is there a reason you'd want chain-length to be totally ordered among all possible chains? The important thing is that there will always be one chain will be greater than or equal to all other existing chains.

Oops, I already re-posted, so too late I guess?

A link to the repost (please continue discussion there): https://bitcointalk.org/index.php?topic=3169968.msg32858330

Am I right that the goals of this protocol are primarily to reduce the finality time in comparison to Bitcoin as well as reduce the cost of running the system?

The image of how blocks are set up (https://cdn-images-1.medium.com/max/1000/1*fPsB4-t6J_1u1UpF37dYHw.png) reminds me strongly of the way blocks are chained in the "two-hop blockchain" (https://eprint.iacr.org/2016/716.pdf). I would like to see more in-depth comparisons to other consensus protocols, especially DPoS which seems particularly close in mechanism to Proof-of-Approval.

Your comparison table claims Proof-of-Approval is fully finalized after a single block,  however, you also talk about how there may be multiple top-level blocks where the "preferred" chain is unresolved. Doesn't this imply that your transaction being inside a valid block doesn't mean its been fully finalized? How do you reconcile that?

Since any node can produce a candidate block, this seems like it would potentially cause unbounded network traffic with everyone and their mother suggesting blocks to vote on. How is this resolved in the case of, say, an adversarial ddos attack? But I have the same question as monsterer2, why would anyone with stake approve the block of anyone without stake? In fact, why would anyone with stake approve *anyone* else's blocks? It seems there's no incentive to mine on top of someone else's blocks. This could manifest in more subtle attacks where you have stakeholders who refuse to mint on top of a competitor. It could also manifest in deadlock as nodes try to maximize their probability of winning the minted block.

I have a hard time seeing the purpose of having nodes pay attention to timestamps and comparing them to their receive-time. At its core, the mechanism is just voting, right? I don't see why the protocol doesn't just let nodes vote for whatever blocks they want. I see the appeal of a simple stake-voting process for block creation (similar to DPoS), but the Proof of Approval method seems like rational profit-seeking minters would make things devolve into the top 50% stakeholders passing around permission to mine the blocks, completely excluding the other 50%.

Also, could you provide a glossary of variables you use in this paper? Its hard for me to keep track of which variables mean what and find their definition in the prose when I need to refer to what they mean later.

@monsterer2 Are you suggesting that greater permissionlessness is desriable? Also, I've come to the conclusion that bootstrap poisoning can be entirely solved by blockchain checkpoints hardcoded into whatever software you use - since the software should be audited, and malicious software can make your client choose whatever chain it wants, hardcoded checkpoints don't reduce security in any meaningful way and yet completely remove the possibility of long range attacks including bootstrap poisoning.

Also @monsterer2 I would actually call your most recent proposed attack a 51% attack, since you *did* own a majority stake, and are using that fact to attack the network. I'd say its just an interesting twist on a 51% attack.

I've written a hybrid PoW/PoS cryptocurrency consensus protocol called Proof of Time Ownership (PoTO) that's intended to be more secure than pure Proof of Work for a given amount of hashpower, and just as secure as pure PoW with a substantially less amount of hashpower (1/2 to 1/10th). I've also detailed and analyzed a number of attacks on PoTO, other hybrid protocols, and pure PoW.

A link to the proposal: https://github.com/fresheneesz/proofOfTimeOwnership

The protocol hinges on a few key design aspects:

• Proof of Work - The protocol still has miners that compete on hashpower to mine transactions into blocks as well as to provide the randomness needed for determining who is allowed to mint PoS blocks
• Time-bound Proof of Stake - PoS minters compete with miners to create blocks. A PoS minter is allowed to mint transactions into a block if one of their addresses comes up in a time-release progression.
• Limiting Miners by held stake - Miners must also hold coins in order to mine, and the proportion of blocks they mine can't exceed the proportion of miner-stake they own. Note that this is detailed as the "Hash-Stake Extension" at the moment - but will likely be incorporated into the protocol as a key (non-extension) component.

In spending a lot of time thinking about this, I believe I've come up with a couple novel attacks not only on hybrid systems, but also on pure PoW itself. I called them "Mining Monopoly Attacks" and I'm curious if anyone has come up with them or discussed them before. The Orphan-based Mining Monopoly Attack is applicable only to hybrid systems that aim to reduce the hashpower needed for a given level of security (like PoTO), but the Economic Mining Monopoly Attack is applicable to both hybrid systems and pure PoW systems, and substantially reduces the theoretical cost of an attack on PoW at equilibrium (ie the cost of acquiring half the hashpower) to half the current amount invested rather than the full current amount invested. For PoW this means the security is half of what you might think, but for hybrid systems, this has more substantial security implications.

I take particular care to compare PoTO to the Proof of Activity proposal by Charlie Lee et al (https://www.decred.org/research/bentov2014.pdf) for which I found a number of security problems not discussed in its paper (or anywhere I've been able to find in my research).

I'm looking for a mathematician to help me analyze the minimum cost of attack for PoTO, since the Hash-stake Extension requires ugly and/or complex math for N>0.

Even at N=0, the introduction of a coin-ownership requirement to mine could substantially increase Bitcoin's security or substantially decrease the required hashpower to maintain Bitcoin's level of security (ie cost of attack), depending on how much staked-coin miners choose to use. Since owning locked-in coins costs much less than depreciation of mining hardware and electricity usage, its likely miners will stake a lot more bitcoins than it would cost them to purchase and run mining equipment. As an example, if 2/3 more bitcoins were staked by miners than currently costs to obtain and run mining hardware, the mining hashpower (and thus on-chain fees) could be reduced to 1/3 of its current amount while still retaining the same security. A second example: if 40% more bitcoins were staked by miners than it would cost to purchase and run mining equipment, the mining hashpower could be reduced to 60% of its current amount while still retaining the same security.

For N>0, the hashpower can be reduced even more while retaining the same security, tho I'm still looking for someone to help me calculate numbers for those (as I mentioned above).

So I'm looking for people to poke holes in this protocol, discuss potential issues and effects, and analyze other effects that haven't yet been explored. But please read the whole proposal before coming to conclusions.

@monsterer2 Thanks, I'll give that a shot! I don't think I could til I posted here and waited for hours, since I'm a new account.

Is this the right section to put this kind of thing?

I've written a hybrid PoW/PoS cryptocurrency consensus protocol called Proof of Time Ownership (PoTO) that is intended to be more secure than pure Proof of Work for a given amount of hashpower, and just as secure as pure PoW with a substantially less amount of hashpower (1/2 to 1/10th). I've also detailed and analyzed a number of attacks on PoTO, other hybrid protocols, and pure PoW.

A link to the proposal: https://github.com/fresheneesz/proofOfTimeOwnership

The protocol hinges on a few key design aspects:

• Proof of Work - The protocol still has miners that compete on hashpower to mine transactions into blocks as well as to provide the randomness needed for determining who is allowed to mint PoS blocks
• Time-bound Proof of Stake - PoS minters compete with miners to create blocks. A PoS minter is allowed to mint transactions into a block if one of their addresses comes up in a time-release progression.
• Limiting Miners by held stake - Miners must also hold coins in order to mine, and the proportion of blocks they mine can't exceed the proportion of miner-stake they own. Note that this is detailed as the "Hash-Stake Extension" at the moment - but will likely be incorporated into the protocol as a key (non-extension) component.

In spending a lot of time thinking about this, I believe I've come up with a couple novel attacks not only on hybrid systems, but also on pure PoW itself. I called them "Mining Monopoly Attacks" and I'm curious if anyone has come up with them or discussed them before. The Orphan-based Mining Monopoly Attack is applicable only to hybrid systems that aim to reduce the hashpower needed for a given level of security (like PoTO), but the Economic Mining Monopoly Attack is applicable to both hybrid systems and pure PoW systems, and substantially reduces the theoretical cost of an attack on PoW at equilibrium (ie the cost of acquiring half the hashpower) to half the current amount invested rather than the full current amount invested. For PoW this means the security is half of what you might think, but for hybrid systems, this has more substantial security implications.

I take particular care to compare PoTO to the Proof of Activity proposal by Charlie Lee et al (https://www.decred.org/research/bentov2014.pdf) for which I found a number of security problems not discussed in its paper (or anywhere I've been able to find in my research).

I'm looking for a mathematician to help me analyze the minimum cost of attack for PoTO, since the Hash-stake Extension requires ugly and/or complex math for N>0.

Even at N=0, the introduction of a coin-ownership requirement to mine could substantially increase Bitcoin's security or substantially decrease the required hashpower to maintain Bitcoin's level of security (ie cost of attack), depending on how much staked-coin miners choose to use. Since owning locked-in coins costs much less than depreciation of mining hardware and electricity usage, its likely miners will stake a lot more bitcoins than it would cost them to purchase and run mining equipment. As an example, if 2/3 more bitcoins were staked by miners than currently costs to obtain and run mining hardware, the mining hashpower (and thus on-chain fees) could be reduced to 1/3 of its current amount while still retaining the same security. A second example: if 40% more bitcoins were staked by miners than it would cost to purchase and run mining equipment, the mining hashpower could be reduced to 60% of its current amount while still retaining the same security.

For N>0, the hashpower can be reduced even more while retaining the same security, tho I'm still looking for someone to help me calculate numbers for those (as I mentioned above).

So I'm looking for people to poke holes in this protocol, discuss potential issues and effects, and analyze other effects that haven't yet been explored. But please read the whole proposal before coming to conclusions.