Re: [bitcoin-dev] Consensus protocol immutability is a feature

[vjudeu via bitcoin-dev]

> Because the above block header format is hashed to generate the 
> `prevBlockHash` for the *next* block, it is almost impossible to change the 
> format without a hardfork.

First, assume that everything should be validated as today to be 
backward-compatible. For that reason, removing SHA-256 is impossible. Then, 
notice that breaking SHA-256 would mean that there would be more and more 
leading zeroes in "prevBlockHash". Breaking SHA-256 fully would mean reaching 
all zeroes hash. So, the old client would see "prevBlockHash" with all zeroes.

Soft-fork means that previously valid blocks could be invalid, so rules should 
be more strict. And that means we could have two headers, one for SHA-256 and 
one for SHA-3. Normally, it would mean that our 80-byte headers would take 160 
bytes instead. But we could compress it a little bit if we share some data.

> * `nVersion`: 4 bytes

Version would be some higher number than today and validated as today. It could 
be shared for both headers.

> * `prevBlockHash`: 32 bytes, SHA2 of previous block.

Previous block hash in SHA-256 would have more and more leading zeroes, so we 
could reuse them and fill with SHA-3 truncated to N bits. In this way, after 
fully breaking SHA-256 it would be fully replaced by SHA-3. Until then, first N 
bits could refer to truncated SHA-3 and the rest to SHA-256. When passing that 
to old nodes, that bits could be zeroed, but all new nodes should see them and 
perform SHA-3 validation.

Example:

SHA-2 of some block: 
0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
SHA-3 of the same data: 
95587d55da5108290c46bac70b622715ae380ef7a313febcc27aeb1c51a28d90
32 bytes stored for that block: 
95587d550019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Of course, we should perform SHA-3 on a different data than used for SHA-2, at 
least merkle root should be recalculated, but it is just an example showing how 
single 32-byte string could store data for both hash functions.

> * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.

If SHA-256 would be broken, then we could use single coinbase transaction to 
prevent doing transactions in the old way. That transaction would contain SHA-3 
of the new merkle root, as you mentioned. New nodes could treat that 
transaction as some kind of annex to the block header, but still doing SHA-2 is 
needed for backward compatibility. For that reason, storing 32 bytes for SHA-2 
and 32 bytes for SHA-3 is needed, unless we have some fast way to get hash with 
all zeroes, then we can save that 32 bytes.

> * `nTime`: 4 bytes, miner-imagined time.

Time should be the same in both headers, so there is no need to duplicate it.

> * `nBits`: 4 bytes, encoded difficulty target

Difficulty should be different for SHA-2 and SHA-3. Finally when SHA-256 would 
be broken, we could reach 0300 for SHA-256 and store only SHA-3 difficulty.

> * `nonce`: 4 bytes, random number with no other meaning.

Nonce should be also different for SHA-2 and SHA-3. If SHA-256 would be fully 
broken, it could be set to zero for SHA-2 and stored only for SHA-3.

On 2021-05-23 20:12:00 user ZmnSCPxj  wrote:
> Good morning vjudeu,
> 
> > > Perhaps the only things that cannot be usefully changed in a softfork is 
> > > the block header format and how proof-of-work is computed from the block 
> > > header.
> >
> > Why not? I can imagine a soft fork where the block header would contain 
> > SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be calculated 
> > as-is, but the SHA-3 would be truncated only to cover zero bits in SHA-256 
> > hashes. In this way, if SHA-256 would be totally broken, old nodes would 
> > see zero hashes in the previous block hash and the merkle tree hash, but 
> > the new nodes would see correct SHA-3 hashes in the same place. So, for 
> > example if we have 1d00 difficulty, the first 32-bits would be zeroes 
> > for all old nodes, but all new nodes would see SHA-3 truncated to 32-bits 
> > in the same place. The difficulty could tell us how many zero bits we 
> > should truncate our SHA-3 result to. Also, in the same way we could 
> > introduce SHA-4 in the future as a soft-fork if SHA-3 would be broken and 
> > we would see many zero bits in our mixed SHA-256 plus SHA-3 consensus.
> 
> I do not think I follow.
> 
> The block header has a Merkle tree root that is a SHA-256 of some Merkle tree 
> node, is that what you refer to?
> Do you mean the same Merkle tree node has to hash to some common value in 
> both SHA-2 and SHA-3?
> 
> Or do you refer to the `prevBlockHash`?
> Do you mean the same `prevBlockHash` has to somehow be the same, for some 
> number of bits, in both SHA-2 and SHA-3?
> 
> More specifically:
> 
> * `nVersion`: 4 bytes
> * `prevBlockHash`: 32 bytes, SHA2 of previous block.
> * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.
> * `nTime`: 4 bytes, miner-imagined time.
> * `nBits`: 4 bytes, encoded difficulty target
> * `nonce`: 4 byte

Re: [bitcoin-dev] Reducing block reward via soft fork

[Karl via bitcoin-dev]

>> The turn-around time for that takes a population of both users and
>> miners to cause. Increasing popularity of bitcoin has a far bigger
>> impact here, and it is already raising fees and energy use at an
>> established rate.
>>
>> If it becomes an issue, as bandwidth increases block size could be
>> raised to lower fees.
>>
>
> Which increases block rewards somewhat (at least to some level that matches
> the overall security of the network) and you still have the same amount of
> energy consumed.

If you mean to implicitly propose that even if halved all the way with
very large blocks, block rewards would just increase to the same
level, meaning that any attempt to decrease them has no effect, I
disagree.I expect that if you raise the block size, eventually
there is so much supply for transactions that there are no fees at all
(nor security).  The numbers are all things the devs, miners, and
users can together control.

> How to prove this is not happening?
> The best you can do is to have some number of authorities sign off on
> whether or not they are doing this.
> The problem is that authorities are bribeable.

You could make the proof of work be a proof of environmental kindness
by coding incentives for people to place and verify proof on the
chain, and then rewarding people for acting on it as desired.  You
could code the chain to pay people to investigate and prove miners'
business practices, for example.  You could define the main chain as
one where everyone consents the proofs are valid.  There are a lot of
issues to resolve and it would be a very different chain.

There is not a single solution here.  There are innumerable possible
solutions, any one of which could be made to work with enough brains
working on it.  To use one, we need to agree on what kinds of
solutions are acceptable.

> Alternately, other entities in the locality can use force to require the
> polluting entity to clean up or suffer significant consequences.
> This at least is better incentive-wise, as they others in the same locality
> are the ones most affected, but the ability to enforce may be difficult due
> to various political constructions; the miners could be in such deep cahoots
> with the local government that the local government would willingly hurt
> other local entities in the vicinity of the polluting entity.

As bitcoin grows, if people ask some locality to enforce behavior,
they may need to be willing to enforce it themselves, too, or they
might outcompete the locality.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Billy Tetrud via bitcoin-dev]

I made a couple typos and mistakes in my couple previous emails:

* "People repeat this often, but the facts support this" -> "the facts *don't
*support this"
* "Together, both of these things reduce PoW's security by a factor of
about 83% (1 - 50%*33%)." -> "factor of about 83% (1 - 50%**(50% - 33%)/50%*)."
(I made a mistake that happened to come out to an almost identical result
coincidentally).
* "And pools could simply require full custody of the coins." -> "*But *pools
could..."

On Sun, May 23, 2021 at 9:10 AM Billy Tetrud  wrote:

> @Lloyd
>
> >  Proof-of-SquareSpace
>
> I agree with your points about delegated proof of stake. I wrote my own
> critique about that
> 
>  as
> well. And your point, that other forms of PoS devolve to DPoS by virtue of
> people wanting to actively mint blocks without exposing their coins in hot
> wallets, is an interesting one.
>
> > how are the users meant to redelegate their stake to honest pools?
>
> This could be mitigated partially if delegation didn't require any kind of
> blockchain transaction. For example, users could simply send a signed
> message saying "this other key can mint blocks with my coins", and then
> minting a block using those coins would require presenting the delegation
> signature. This only partially mitigates the problem since the dishonest
> pool would still be able to use those coins as well, so it would be a race
> at that point. Still better than nothing. And pools could simply require
> full custody of the coins.
>
> From what you mentioned, it sounds like maybe Algorand does something
> similar to this.
>
> > I don't see a way to get around the conflicting requirement that the
> keys for large amounts of coins should be kept offline but those are
> exactly the coins we need online to make the scheme secure.
>
> There are a couple solutions you didn't mention. One is your "traditional"
> locked-stake kind of systems, where participants are required to lock their
> stake for long periods of time. Since normal users aren't likely to want to
> do this, it will likely be left to more sophisticated stakers likely
> staking very large amounts.
>
> Both mechanisms you mentioned allow delegation, and it might seem like
> maybe there'd be a way to disallow delegation, however since users can
> always give custody of their coins to trusted pools, that would be a
> delgation mechanism of last resort that can't be removed. So you can do
> things that make it hard (for both users and pool operators) to delegate
> trustlessly, but you can't get rid of the ability to delgate entirely.
>
> In general, the situations where I see people not pooling are:
>
> A. They are entirely prevented by technical means. It seems reasonably
> clear that this is impossible.
> B. The downsides are more than unsophisticated users are willing to incur
> (eg stake locking).
> C. The rewards are so small that it isn't worth it for people to put in
> much effort to gain them.
> D. The rewards are so frequent that pooling is unnecessary.
>
> B excludes a lot of people from being able to help secure the chain, but
> this is not materially different from PoW mining in that regard. D is a bit
> border line. With 1 billion people attempting to participate and 10 minute
> blocks, 232 people would need to share the block reward in order to expect
> a payout on average once per month. With 8 billion people that would turn
> into more like 1700 people. This seems potentially doable (eg via cosigner
> requirements on minted blocks), but it is a lot of participants per block.
>
> I think options C and D combined would be an ideal approach here. Because
> minting uses very few real resources, minting could be pretty much have
> arbitrarily low ongoing costs. This means fees can be low and blocks can
> have low payouts. If the reward was low and people could expect to see it
> once every couple years, people could simply treat it like a lottery. Great
> if they win it now, but nothing that anyone needs to rely on (which would
> incentivize the pools to reduce variance that we want to avoid). If there
> is no locked stake or other major barriers in place to minting blocks, that
> would also help avoid the compultion to use a pool.
>
> In any case, you bring up good points, and they certainly complicate the
> issue. By the way, if you were confused as to what VPoS was in the section
> from my above link, this might satisfy your curiosity
> .
>
> Cheers
>
>
>
>
> On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier 
> wrote:
>
>> Hi Billy,
>>
>> I was going to write a post which started by dismissing many of the weak
>> arguments that are made against PoS made in this thread and elsewhere.
>> Although I don't agree with all your points you have done a decent job
>> here so I'll focus on the second part: why I think Proof-of-Stake i

Re: [bitcoin-dev] Opinion on proof of stake in future

[Billy Tetrud via bitcoin-dev]

@Lloyd

>  Proof-of-SquareSpace

I agree with your points about delegated proof of stake. I wrote my own
critique about that

as
well. And your point, that other forms of PoS devolve to DPoS by virtue of
people wanting to actively mint blocks without exposing their coins in hot
wallets, is an interesting one.

> how are the users meant to redelegate their stake to honest pools?

This could be mitigated partially if delegation didn't require any kind of
blockchain transaction. For example, users could simply send a signed
message saying "this other key can mint blocks with my coins", and then
minting a block using those coins would require presenting the delegation
signature. This only partially mitigates the problem since the dishonest
pool would still be able to use those coins as well, so it would be a race
at that point. Still better than nothing. And pools could simply require
full custody of the coins.

>From what you mentioned, it sounds like maybe Algorand does something
similar to this.

> I don't see a way to get around the conflicting requirement that the keys
for large amounts of coins should be kept offline but those are exactly the
coins we need online to make the scheme secure.

There are a couple solutions you didn't mention. One is your "traditional"
locked-stake kind of systems, where participants are required to lock their
stake for long periods of time. Since normal users aren't likely to want to
do this, it will likely be left to more sophisticated stakers likely
staking very large amounts.

Both mechanisms you mentioned allow delegation, and it might seem like
maybe there'd be a way to disallow delegation, however since users can
always give custody of their coins to trusted pools, that would be a
delgation mechanism of last resort that can't be removed. So you can do
things that make it hard (for both users and pool operators) to delegate
trustlessly, but you can't get rid of the ability to delgate entirely.

In general, the situations where I see people not pooling are:

A. They are entirely prevented by technical means. It seems reasonably
clear that this is impossible.
B. The downsides are more than unsophisticated users are willing to incur
(eg stake locking).
C. The rewards are so small that it isn't worth it for people to put in
much effort to gain them.
D. The rewards are so frequent that pooling is unnecessary.

B excludes a lot of people from being able to help secure the chain, but
this is not materially different from PoW mining in that regard. D is a bit
border line. With 1 billion people attempting to participate and 10 minute
blocks, 232 people would need to share the block reward in order to expect
a payout on average once per month. With 8 billion people that would turn
into more like 1700 people. This seems potentially doable (eg via cosigner
requirements on minted blocks), but it is a lot of participants per block.

I think options C and D combined would be an ideal approach here. Because
minting uses very few real resources, minting could be pretty much have
arbitrarily low ongoing costs. This means fees can be low and blocks can
have low payouts. If the reward was low and people could expect to see it
once every couple years, people could simply treat it like a lottery. Great
if they win it now, but nothing that anyone needs to rely on (which would
incentivize the pools to reduce variance that we want to avoid). If there
is no locked stake or other major barriers in place to minting blocks, that
would also help avoid the compultion to use a pool.

In any case, you bring up good points, and they certainly complicate the
issue. By the way, if you were confused as to what VPoS was in the section
from my above link, this might satisfy your curiosity
.

Cheers




On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier 
wrote:

> Hi Billy,
>
> I was going to write a post which started by dismissing many of the weak
> arguments that are made against PoS made in this thread and elsewhere.
> Although I don't agree with all your points you have done a decent job
> here so I'll focus on the second part: why I think Proof-of-Stake is
> inappropriate for a Bitcoin-like system.
>
> Proof of stake is not fit for purpose for a global settlement layer in a
> pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to
> be.
> PoS necessarily gives responsibilities to the holders of coins that they
> do not want and cannot handle.
> In Bitcoin, large unsophisticated coin holders can put their coins in cold
> storage without a second thought given to the health of the underlying
> ledger.
> As much as hardcore Bitcoiners try to convince them to run their own node,
> most don't, and that's perfectly acceptable.
> At no point do their personal decisions affect the underlying consensus --
> it only affects their 

Re: [bitcoin-dev] Consensus protocol immutability is a feature

[ZmnSCPxj via bitcoin-dev]

Good morning vjudeu,

> > Perhaps the only things that cannot be usefully changed in a softfork is 
> > the block header format and how proof-of-work is computed from the block 
> > header.
>
> Why not? I can imagine a soft fork where the block header would contain 
> SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be calculated 
> as-is, but the SHA-3 would be truncated only to cover zero bits in SHA-256 
> hashes. In this way, if SHA-256 would be totally broken, old nodes would see 
> zero hashes in the previous block hash and the merkle tree hash, but the new 
> nodes would see correct SHA-3 hashes in the same place. So, for example if we 
> have 1d00 difficulty, the first 32-bits would be zeroes for all old 
> nodes, but all new nodes would see SHA-3 truncated to 32-bits in the same 
> place. The difficulty could tell us how many zero bits we should truncate our 
> SHA-3 result to. Also, in the same way we could introduce SHA-4 in the future 
> as a soft-fork if SHA-3 would be broken and we would see many zero bits in 
> our mixed SHA-256 plus SHA-3 consensus.

I do not think I follow.

The block header has a Merkle tree root that is a SHA-256 of some Merkle tree 
node, is that what you refer to?
Do you mean the same Merkle tree node has to hash to some common value in both 
SHA-2 and SHA-3?

Or do you refer to the `prevBlockHash`?
Do you mean the same `prevBlockHash` has to somehow be the same, for some 
number of bits, in both SHA-2 and SHA-3?

More specifically:

* `nVersion`: 4 bytes
* `prevBlockHash`: 32 bytes, SHA2 of previous block.
* `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.
* `nTime`: 4 bytes, miner-imagined time.
* `nBits`: 4 bytes, encoded difficulty target
* `nonce`: 4 bytes, random number with no other meaning.

What do you refer to?

Because the above block header format is hashed to generate the `prevBlockHash` 
for the *next* block, it is almost impossible to change the format without a 
hardfork.

Regaards,
ZmnSCPxj

>
> On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Good morning Jorge, et al,
> >
> > > Hardforks can be useful too.
> > > But, yes, I agree softforks are preferable whenever possible.
> >
> > I think in principle the space of possible softforks is very much wider 
> > than can be trivially expected.
> > For instance, maaku7 once proposed a softfork that could potentially change 
> > the block discovery rate as a softfork.
> > Although this required exploiting a consensus bug that has since been 
> > closed.
> > The example of SegWit shows us that we can in fact create massive changes 
> > to the transaction and block formats with a softfork.
> > For example, it is possible to change the Merkle Tree to use SHA3 instead, 
> > in a softfork, by requiring that miners no longer use the "normal" existing 
> > Merkle Tree, but instead to require miners to embed a commitment to the 
> > SHA3-Merkle-Tree on the coinbase of the "original" block format, and to 
> > build "empty" SHA2-Merkle-Trees containing only the coinbase.
> > To unupgraded nodes it looks as if there is a denial-of-service attack 
> > permanently, while upgraded nodes will seek blocks that conform to the 
> > SHA3-Merkle-Tree embedded in the coinbase.
> > (Do note that this definition of "softfork" is the "> 50% of miners is 
> > enough to pull everyone to the fork".
> > Some thinkers have a stricter definition of "softfork" as "non-upgraded 
> > nodes can still associate addresses to values in the UTXO set but might not 
> > be able to detect consensus rules violations in new address types", which 
> > fits SegWit and Taproot.)
> > (In addition, presumably the reason to switch to SHA3 is to avoid potential 
> > preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tree, 
> > so... this is a bad example)
> > Perhaps the only things that cannot be usefully changed in a softfork is 
> > the block header format and how proof-of-work is computed from the block 
> > header.
> > But the flexibility of the coinbase allows us to hook new commitments to 
> > new Merkle Trees to it, which allows transactions to be annotated with 
> > additional information that is invisible to unupgraded nodes (similar to 
> > the `witness` field of SegWit transactions).
> >
> > Even if you do have a softfork, we should be reminded to look at the 
> > histories of SegWit and Taproot.
> > SegWit became controversial later on, which delayed its activation.
> > On the other hand, Taproot had no significant controversy and it was widely 
> > accepted as being a definite improvement to the network.
> > Yet its implementation and deployment still took a long time, and there was 
> > still controversy on how to properly implement the activation code.
> > Any hardforks would not only have to go through the hurdles that Taproot 
> > and SegWit had to go through, but will also have to pass through the much 
> > higher hurdle of being a ha

Re: [bitcoin-dev] Tweaking tapscript instead of public key

[Ruben Somsen via bitcoin-dev]

Hi,

That's an excellent question, but note that answering such questions is not
the primary function of this mailing list. Places like Bitcoin Stack
Exchange or even IRC are probably better for that!

Specific to your question: in Taproot Q = P + hash(P||m)*G. The fact that P
is hashed together with the message, makes it a commitment. If you try to
change m to e.g. m2, then Q - hash(P||m2) will never result in P (unless
the hash function is broken).

The original Taproot thread can be found here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html

Cheers,
Ruben

On Sun, May 23, 2021 at 7:10 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> As far as I know, P2TR address contains 32-byte public key. It can be used
> directly by creating Schnorr signature or indirectly, by revealing
> tapscript. Does it mean that any taproot output could be modified
> on-the-fly after being confirmed without changing an address? I mean, if we
> have base point as the private key with P2TR address
> tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz, then the
> owner of that key can modify spending conditions without moving on-chain
> coins?
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus protocol immutability is a feature

[vjudeu via bitcoin-dev]

> Perhaps the only things that cannot be usefully changed in a softfork is the 
> block header format and how proof-of-work is computed from the block header.

Why not? I can imagine a soft fork where the block header would contain SHA-256 
and SHA-3 hashes in the same place. The SHA-256 would be calculated as-is, but 
the SHA-3 would be truncated only to cover zero bits in SHA-256 hashes. In this 
way, if SHA-256 would be totally broken, old nodes would see zero hashes in the 
previous block hash and the merkle tree hash, but the new nodes would see 
correct SHA-3 hashes in the same place. So, for example if we have 1d00 
difficulty, the first 32-bits would be zeroes for all old nodes, but all new 
nodes would see SHA-3 truncated to 32-bits in the same place. The difficulty 
could tell us how many zero bits we should truncate our SHA-3 result to. Also, 
in the same way we could introduce SHA-4 in the future as a soft-fork if SHA-3 
would be broken and we would see many zero bits in our mixed SHA-256 plus SHA-3 
consensus.

On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev 
 wrote:
> Good morning Jorge, et al,
> 
> > Hardforks can be useful too.
> > But, yes, I agree softforks are preferable whenever possible.
> 
> I think in principle the space of possible softforks is very much wider than 
> can be trivially expected.
> 
> For instance, maaku7 once proposed a softfork that could potentially change 
> the block discovery rate as a softfork.
> Although this required exploiting a consensus bug that has since been closed.
> 
> The example of SegWit shows us that we can in fact create massive changes to 
> the transaction and block formats with a softfork.
> 
> For example, it is possible to change the Merkle Tree to use SHA3 instead, in 
> a softfork, by requiring that miners no longer use the "normal" existing 
> Merkle Tree, but instead to require miners to embed a commitment to the 
> SHA3-Merkle-Tree on the coinbase of the "original" block format, and to build 
> "empty" SHA2-Merkle-Trees containing only the coinbase.
> To unupgraded nodes it looks as if there is a denial-of-service attack 
> permanently, while upgraded nodes will seek blocks that conform to the 
> SHA3-Merkle-Tree embedded in the coinbase.
> 
> (Do note that this definition of "softfork" is the "> 50% of miners is enough 
> to pull everyone to the fork".
> Some thinkers have a stricter definition of "softfork" as "non-upgraded nodes 
> can still associate addresses to values in the UTXO set but might not be able 
> to detect consensus rules violations in new address types", which fits SegWit 
> and Taproot.)
> 
> (In addition, presumably the reason to switch to SHA3 is to avoid potential 
> preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tree, 
> so... this is a bad example)
> 
> Perhaps the only things that cannot be usefully changed in a softfork is the 
> block header format and how proof-of-work is computed from the block header.
> But the flexibility of the coinbase allows us to hook new commitments to new 
> Merkle Trees to it, which allows transactions to be annotated with additional 
> information that is invisible to unupgraded nodes (similar to the `witness` 
> field of SegWit transactions).
> 
> 
> 
> 
> 
> Even if you *do* have a softfork, we should be reminded to look at the 
> histories of SegWit and Taproot.
> 
> SegWit became controversial later on, which delayed its activation.
> 
> On the other hand, Taproot had no significant controversy and it was widely 
> accepted as being a definite improvement to the network.
> Yet its implementation and deployment still took a long time, and there was 
> still controversy on how to properly implement the activation code.
> 
> Any hardforks would not only have to go through the hurdles that Taproot and 
> SegWit had to go through, but will *also* have to pass through the much 
> higher hurdle of being a hardfork.
> 
> Thus, anyone contemplating a hardfork, for any reason, must be prepared to 
> work on it for several **years** before anyone even frowns and says "hmm 
> maybe" instead of everyone just outright dismissing it with a simple 
> "hardfork = hard pass".
> As a simple estimate, I would assume that any hardfork would require twice 
> the average amount of engeineering-manpower involved in SegWit and Taproot.
> (this assumes that hardforks are only twice as hard as softforks --- this 
> estimate may be wrong, and this might provide only a minimum rather than an 
> expected average)
> 
> There are no quick solutions in this space.
> Either we work with what we have and figure out how to get around issues with 
> no real capability to fix them at the base layer, or we have insight on 
> future problems and start working on future solutions today.
> For example, I know at least one individual was maintaining an "emergency" 
> branch to add some kind of post-quantum signature scheme to Bitcoin, in case 
> of a quantum break.
> 
> Regards

[bitcoin-dev] Tweaking tapscript instead of public key

[vjudeu via bitcoin-dev]

As far as I know, P2TR address contains 32-byte public key. It can be used 
directly by creating Schnorr signature or indirectly, by revealing tapscript. 
Does it mean that any taproot output could be modified on-the-fly after being 
confirmed without changing an address? I mean, if we have base point as the 
private key with P2TR address 
tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz, then the owner 
of that key can modify spending conditions without moving on-chain coins?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: Reducing block reward via soft fork

[James Lu via bitcoin-dev]

> Well, it is done automatically every 4 years :)
Bitcoin's price has always been increasing exponentially faster than the
block size has been exponentially decreasing.

> It is a self-balancing system - more people shout about Bitcoin being
dirty -> less adoption -> lower the price -> less energy consumption.
Surely we can strive for adoption and be environmentally friendly?

Bitcoin currently consumes as much power as a small nation-state, giving it
nation-state security. A 51% attack can reverse recent transactions. I
don't think 99% of transactions need that level of security– and if we
don't improve environmental-friendliness, adoption will decrease, so the
price will decrease, so less mining will happen, so security will be hurt
anyway.

> I am all for making Bitcoin green(er), but IMHO there shall be no
short-termism of the sort "Elon complained + price dropped 40% - lets go
radically change things".
I agree, Bitcoin shouldn't do anything just because a celebrity said
something. However, this would be the ideal time to make such a change,
riding off the public attitude to build social consensus around such a
change.

Also, this reduces inflation, good for Bitcoin hodlers ;)

> IMHO if we want to make BTC cleaner we can add functionality where users
can prioritise some miners over the others, with the view that users will
prioritise "green" miners and they will get more TX fees, and there will be
economic incentive to go green.
This proposal would be great too.

On Sun, May 23, 2021 at 6:42 AM Anton Ragin  wrote:

> Well, it is done automatically every 4 years :) It is a self-balancing
> system - more people shout about Bitcoin being dirty -> less adoption ->
> lower the price -> less energy consumption. Add on top the fact that in
> 2024 block rewards will fall 50% anyway and someday it will be zero.
>
> I am all for making Bitcoin green(er), but IMHO there shall be no
> short-termism of the sort "Elon complained + price dropped 40% - lets go
> radically change things".
>
> IMHO if we want to make BTC cleaner we can add functionality where users
> can prioritise some miners over the others, with the view that users will
> prioritise "green" miners and they will get more TX fees, and there will be
> economic incentive to go green.
>
> On Sun, 23 May 2021, 09:49 James Lu via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Background
>> ===
>> Reducing the block reward reduces the incentive to mine. It reduces the
>> maximum energy price at which mining is profitable, reducing the energy use.
>>
>> Bitcoins have value because they are accepted by full node users, from
>> individual node operators, to exchanges and custodians like Coinbase.
>> Anything else and the Bitcoins don't exist and are worthless. Like all
>> currencies, Bitcoin has value because others recognize that they have value.
>>
>> Idea
>> ===
>> Reduce the block reward by adding fewer coins to the UTXO set per block.
>> This should be done gradually
>>
>> Consensus layer
>> ===
>> This is a soft fork, because it tightens the
>>
>> Some Possible Weaknesses
>> ===
>> - It will cost less than a nation-state of energy to reverse recent
>> Bitcoin transactions.
>> - Some miners may protest and lobby exchanges.
>> - By pushing mining towards the cheapest energy sources, centralization
>> increases towards Chinese miners.
>> - The Bitcoin network may split if consensus is not built before flag day.
>>
>> However, given the current political headwinds and widespread public
>> discussion around Bitcoin's energy use, it may be socially possible to
>> ask individual users and major exchanges to install a version of Bitcoin
>> with a reduced block reward.
>>
>> Alternatives
>> ===
>> Instead of outright rejecting transactions (and the blocks that contain
>> them) that attempt to spend increased block rewards, treat them as no-ops.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[ZmnSCPxj via bitcoin-dev]

Good morning Karl,

> On 5/23/21, ZmnSCPxj via bitcoin-dev
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Good morning James,
> >
> > > Background
> > >
> > > ===
> > >
> > > Reducing the block reward reduces the incentive to mine. It reduces the
> > > maximum energy price at which mining is profitable, reducing the energy
> > > use.
> >
> > If people want to retain previous levels of security, they can offer to pay
> > higher fees, which increases the miner reward and thereby increasing the
> > energy use again.
>
> The turn-around time for that takes a population of both users and
> miners to cause. Increasing popularity of bitcoin has a far bigger
> impact here, and it is already raising fees and energy use at an
> established rate.
>
> If it becomes an issue, as bandwidth increases block size could be
> raised to lower fees.
>

Which increases block rewards somewhat (at least to some level that matches the 
overall security of the network) and you still have the same amount of energy 
consumed.

> > Properly account for the entropy increase (energy usage) of all kinds of
> > pollution, and the free market will naturally seek sustainable and renewable
> > processes --- because that maximizes profitability in the long run.
>
> There is little economic incentive to fine carbon emissions because
> there is no well-established quick path to gain profit from reducing
> them. The feedback paths you describe take decades if not hundreds of
> years.
>
> But it sounds like you are saying you would rather the energy issue
> stay a political one that does not involve bitcoin. Your point is
> quite relevant because bitcoin is not the largest consumer of energy;
> those who care about reducing energy use would be better put to look
> at other concerns.

Precisely.

> > What is needed is to enforce that pollution be paid for by those who cause
> > it --- this can require significant political influence to do (a major world
> > government is a major polluter, willing to pay for high fuel costs just to
> > ship their soldiers globally, polluting the environments of foreign
> > countries), and should be what true environmentalists would work towards,
> > not rejecting Bitcoin as an environmental disaster (which is frankly
> > laughable).
> > Remember, the free market only works correctly if all its costs are
> > accounted correctly --- otherwise it will treat costs subsidized by the
> > community of human beings as a resource to pump.
>
> It sounds like you would prefer a proof-of-work function that directly
> proved carbon offsetting? And an on-chain tax for environmental harm?


The problem is that the only proof of efficiency here is implicit: any 
inefficiency will eventually be rooted out of the network, as any inefficiency 
will translate to reduced profitability.
However, at short-term, a miner can pollute its locality, and then exit the 
business and leave its crap lying around for others to deal with and abscond 
with pure profit.
This translates to a theft in the profitability of others in the locality.

How to prove this is not happening?
The best you can do is to have some number of authorities sign off on whether 
or not they are doing this.
The problem is that authorities are bribeable.

Alternately, other entities in the locality can use force to require the 
polluting entity to clean up or suffer significant consequences.
This at least is better incentive-wise, as they others in the same locality are 
the ones most affected, but the ability to enforce may be difficult due to 
various political constructions; the miners could be in such deep cahoots with 
the local government that the local government would willingly hurt other local 
entities in the vicinity of the polluting entity.



Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[Karl via bitcoin-dev]

On 5/23/21, ZmnSCPxj via bitcoin-dev
 wrote:
> Good morning James,
>
>> Background
>> ===
>> Reducing the block reward reduces the incentive to mine. It reduces the
>> maximum energy price at which mining is profitable, reducing the energy
>> use.
>>
>
> If people want to retain previous levels of security, they can offer to pay
> higher fees, which increases the miner reward and thereby increasing the
> energy use again.

The turn-around time for that takes a population of both users and
miners to cause.  Increasing popularity of bitcoin has a far bigger
impact here, and it is already raising fees and energy use at an
established rate.

If it becomes an issue, as bandwidth increases block size could be
raised to lower fees.

> Properly account for the entropy increase (energy usage) of all kinds of
> pollution, and the free market will naturally seek sustainable and renewable
> processes --- because that maximizes profitability in the long run.

There is little economic incentive to fine carbon emissions because
there is no well-established quick path to gain profit from reducing
them.  The feedback paths you describe take decades if not hundreds of
years.

But it sounds like you are saying you would rather the energy issue
stay a political one that does not involve bitcoin.  Your point is
quite relevant because bitcoin is not the largest consumer of energy;
those who care about reducing energy use would be better put to look
at other concerns.

The reason to reduce _bitcoin's_ energy use, would simply be to aid
its popularity and quell public concern.  Without doing this, people
move to an altcoin, because increasing the value of bitcoin via
spreading its use, increases the demand for mining.  That human
decision is part of the honesty you describe.

> What is needed is to enforce that pollution be paid for by those who cause
> it --- this can require significant political influence to do (a major world
> government is a major polluter, willing to pay for high fuel costs just to
> ship their soldiers globally, polluting the environments of foreign
> countries), and should be what true environmentalists would work towards,
> not rejecting Bitcoin as an environmental disaster (which is frankly
> laughable).
>
> Remember, the free market only works correctly if all its costs are
> accounted correctly --- otherwise it will treat costs subsidized by the
> community of human beings as a resource to pump.

It sounds like you would prefer a proof-of-work function that directly
proved carbon offsetting?  And an on-chain tax for environmental harm?

On 5/23/21, Anton Ragin via bitcoin-dev
 wrote:
> Well, it is done automatically every 4 years :) It is a self-balancing
> system - more people shout about Bitcoin being dirty -> less adoption ->
> lower the price -> less energy consumption. Add on top the fact that in
> 2024 block rewards will fall 50% anyway and someday it will be zero.

Is hashrate rising slower than the block reward is dropping, that you
mention the 4 years halving?  Do you see a problem with dropping the
block reward to make faster change to the hashrate curve, that you
mention the existing system's weaker approach?

I personally wasn't aware that Elon had complained; I've been hearing
the complaint from scads of people for many years.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[Anton Ragin via bitcoin-dev]

Well, it is done automatically every 4 years :) It is a self-balancing
system - more people shout about Bitcoin being dirty -> less adoption ->
lower the price -> less energy consumption. Add on top the fact that in
2024 block rewards will fall 50% anyway and someday it will be zero.

I am all for making Bitcoin green(er), but IMHO there shall be no
short-termism of the sort "Elon complained + price dropped 40% - lets go
radically change things".

IMHO if we want to make BTC cleaner we can add functionality where users
can prioritise some miners over the others, with the view that users will
prioritise "green" miners and they will get more TX fees, and there will be
economic incentive to go green.

On Sun, 23 May 2021, 09:49 James Lu via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Background
> ===
> Reducing the block reward reduces the incentive to mine. It reduces the
> maximum energy price at which mining is profitable, reducing the energy use.
>
> Bitcoins have value because they are accepted by full node users, from
> individual node operators, to exchanges and custodians like Coinbase.
> Anything else and the Bitcoins don't exist and are worthless. Like all
> currencies, Bitcoin has value because others recognize that they have value.
>
> Idea
> ===
> Reduce the block reward by adding fewer coins to the UTXO set per block.
> This should be done gradually
>
> Consensus layer
> ===
> This is a soft fork, because it tightens the
>
> Some Possible Weaknesses
> ===
> - It will cost less than a nation-state of energy to reverse recent
> Bitcoin transactions.
> - Some miners may protest and lobby exchanges.
> - By pushing mining towards the cheapest energy sources, centralization
> increases towards Chinese miners.
> - The Bitcoin network may split if consensus is not built before flag day.
>
> However, given the current political headwinds and widespread public
> discussion around Bitcoin's energy use, it may be socially possible to
> ask individual users and major exchanges to install a version of Bitcoin
> with a reduced block reward.
>
> Alternatives
> ===
> Instead of outright rejecting transactions (and the blocks that contain
> them) that attempt to spend increased block rewards, treat them as no-ops.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Reducing block reward via soft fork

[ZmnSCPxj via bitcoin-dev]

Good morning James,

> Background
> ===
> Reducing the block reward reduces the incentive to mine. It reduces the 
> maximum energy price at which mining is profitable, reducing the energy use.
>

If people want to retain previous levels of security, they can offer to pay 
higher fees, which increases the miner reward and thereby increasing the energy 
use again.
The only difference is that the security is paid for directly by transactors 
rather than slowly extracted from HODLers.

Thus, I expect that the energy use of Bitcoin will fairly closely match its 
security usage, even with this change.

Really, though:

* The issue is not energy use.
* The issue is the energy *efficiency*.

Everything important requires energy.
What is needed is to get the most amount of work for the least amount of 
entropy-increase.

Deleterious environmental effects (pollution, temperature rise, and so on) are 
symptoms of entropy-increase in the local universe.
These have long-term negative effects from the simple fact that we are 
producing entropy and dumping it into our surroundings.

If these effects are properly charged to their instigators (e.g. carbon 
emissions fines), then the negative environmental effects will become economic 
disincentives, that miners will now naturally avoid in order to increase their 
profitability.
This holds no matter how much block rewards are, and how much comes from the 
block subsidy or from mining fees.

The trope that the "free market" is somehow opposed to "environmentalism" is 
about as accurate to real life as Hollywood hacking "I can crack AES-256 in 
exactly 30 minutes".
Properly account for the entropy increase (energy usage) of all kinds of 
pollution, and the free market will naturally seek sustainable and renewable 
processes --- because that maximizes profitability in the long run.
Anyone who pushes for environmentalism but refuses to use Bitcoin should be 
treated with suspicion of either hypocrisy or massive ignorance --- Bitcoin is 
the most honest currency in accounting for its energy usage and consumption, 
and I suspect most other currencies have far worse efficiencies, that happen to 
be hidden because they are not properly accounted for.

What is needed is to enforce that pollution be paid for by those who cause it 
--- this can require significant political influence to do (a major world 
government is a major polluter, willing to pay for high fuel costs just to ship 
their soldiers globally, polluting the environments of foreign countries), and 
should be what true environmentalists would work towards, not rejecting Bitcoin 
as an environmental disaster (which is frankly laughable).
Remember, the free market only works correctly if all its costs are accounted 
correctly --- otherwise it will treat costs subsidized by the community of 
human beings as a resource to pump.

> Alternatives
> ===
> Instead of outright rejecting transactions (and the blocks that contain them) 
> that attempt to spend increased block rewards, treat them as no-ops.

That is inefficient --- the "no-op" transactions reduce the available block 
space for operational transactions, thus this alternative is strictly inferior 
to a simple acceleration of block subsidy reduction.

Regards,
ZmnSCPXj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus protocol immutability is a feature

[ZmnSCPxj via bitcoin-dev]

Good morning Jorge, et al,

> Hardforks can be useful too.
> But, yes, I agree softforks are preferable whenever possible.

I think in principle the space of possible softforks is very much wider than 
can be trivially expected.

For instance, maaku7 once proposed a softfork that could potentially change the 
block discovery rate as a softfork.
Although this required exploiting a consensus bug that has since been closed.

The example of SegWit shows us that we can in fact create massive changes to 
the transaction and block formats with a softfork.

For example, it is possible to change the Merkle Tree to use SHA3 instead, in a 
softfork, by requiring that miners no longer use the "normal" existing Merkle 
Tree, but instead to require miners to embed a commitment to the 
SHA3-Merkle-Tree on the coinbase of the "original" block format, and to build 
"empty" SHA2-Merkle-Trees containing only the coinbase.
To unupgraded nodes it looks as if there is a denial-of-service attack 
permanently, while upgraded nodes will seek blocks that conform to the 
SHA3-Merkle-Tree embedded in the coinbase.

(Do note that this definition of "softfork" is the "> 50% of miners is enough 
to pull everyone to the fork".
Some thinkers have a stricter definition of "softfork" as "non-upgraded nodes 
can still associate addresses to values in the UTXO set but might not be able 
to detect consensus rules violations in new address types", which fits SegWit 
and Taproot.)

(In addition, presumably the reason to switch to SHA3 is to avoid potential 
preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tree, 
so... this is a bad example)

Perhaps the only things that cannot be usefully changed in a softfork is the 
block header format and how proof-of-work is computed from the block header.
But the flexibility of the coinbase allows us to hook new commitments to new 
Merkle Trees to it, which allows transactions to be annotated with additional 
information that is invisible to unupgraded nodes (similar to the `witness` 
field of SegWit transactions).





Even if you *do* have a softfork, we should be reminded to look at the 
histories of SegWit and Taproot.

SegWit became controversial later on, which delayed its activation.

On the other hand, Taproot had no significant controversy and it was widely 
accepted as being a definite improvement to the network.
Yet its implementation and deployment still took a long time, and there was 
still controversy on how to properly implement the activation code.

Any hardforks would not only have to go through the hurdles that Taproot and 
SegWit had to go through, but will *also* have to pass through the much higher 
hurdle of being a hardfork.

Thus, anyone contemplating a hardfork, for any reason, must be prepared to work 
on it for several **years** before anyone even frowns and says "hmm maybe" 
instead of everyone just outright dismissing it with a simple "hardfork = hard 
pass".
As a simple estimate, I would assume that any hardfork would require twice the 
average amount of engeineering-manpower involved in SegWit and Taproot.
(this assumes that hardforks are only twice as hard as softforks --- this 
estimate may be wrong, and this might provide only a minimum rather than an 
expected average)

There are no quick solutions in this space.
Either we work with what we have and figure out how to get around issues with 
no real capability to fix them at the base layer, or we have insight on future 
problems and start working on future solutions today.
For example, I know at least one individual was maintaining an "emergency" 
branch to add some kind of post-quantum signature scheme to Bitcoin, in case of 
a quantum break.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Reducing block reward via soft fork

[James Lu via bitcoin-dev]

Background
===
Reducing the block reward reduces the incentive to mine. It reduces the
maximum energy price at which mining is profitable, reducing the energy use.

Bitcoins have value because they are accepted by full node users, from
individual node operators, to exchanges and custodians like Coinbase.
Anything else and the Bitcoins don't exist and are worthless. Like all
currencies, Bitcoin has value because others recognize that they have value.

Idea
===
Reduce the block reward by adding fewer coins to the UTXO set per block.
This should be done gradually

Consensus layer
===
This is a soft fork, because it tightens the

Some Possible Weaknesses
===
- It will cost less than a nation-state of energy to reverse recent Bitcoin
transactions.
- Some miners may protest and lobby exchanges.
- By pushing mining towards the cheapest energy sources, centralization
increases towards Chinese miners.
- The Bitcoin network may split if consensus is not built before flag day.

However, given the current political headwinds and widespread public
discussion around Bitcoin's energy use, it may be socially possible to ask
individual users and major exchanges to install a version of Bitcoin with a
reduced block reward.

Alternatives
===
Instead of outright rejecting transactions (and the blocks that contain
them) that attempt to spend increased block rewards, treat them as no-ops.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Opinion on proof of stake in future

[Lloyd Fournier via bitcoin-dev]

Hi Billy,

I was going to write a post which started by dismissing many of the weak
arguments that are made against PoS made in this thread and elsewhere.
Although I don't agree with all your points you have done a decent job here
so I'll focus on the second part: why I think Proof-of-Stake is
inappropriate for a Bitcoin-like system.

Proof of stake is not fit for purpose for a global settlement layer in a
pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to
be.
PoS necessarily gives responsibilities to the holders of coins that they do
not want and cannot handle.
In Bitcoin, large unsophisticated coin holders can put their coins in cold
storage without a second thought given to the health of the underlying
ledger.
As much as hardcore Bitcoiners try to convince them to run their own node,
most don't, and that's perfectly acceptable.
At no point do their personal decisions affect the underlying consensus --
it only affects their personal security assurance (not that of the system
itself).
In PoS systems this clean separation of responsibilities does not exist.

I think that the more rigorously studied PoS protocols will work fine
within the security claims made in their papers.
People who believe that these protocols are destined for catastrophic
consensus failure are certainly in for a surprise.
But the devil is in the detail.
Let's look at what the implications of using the leading proof of stake
protocols would have on Bitcoin:

### Proof of SquareSpace (Cardano, Polkdadot)

Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an
inbuilt on-chain delegation system[5].
In these protocols, coin holders who do not want to run their node with
their hot keys in it delegate it to a "Stake Pool".
I call the resulting system Proof-of-SquareSpace since most will choose a
pool by looking around for one with a nice website and offering the largest
share of the block reward.
On the surface this might sound no different than someone with an mining
rig shopping around for a good mining pool but there are crucial
differences:

1. The person making the decision is forced into it just because they own
the currency -- someone with a mining rig has purchased it with the intent
to make profit by participating in consensus.

2. When you join a mining pool your systems are very much still online. You
are just partaking in a pool to reduce your profit variance. You still see
every block that you help create and *you never help create a block without
seeing it first*.

3. If by SquareSpace sybil attack you gain a dishonest majority and start
censoring transactions how are the users meant to redelegate their stake to
honest pools?
I guess they can just send a transaction delegating to another pool...oh
wait I guess that might be censored too! This seems really really bad.
In Bitcoin, miners can just join a different pool at a whim. There is
nothing the attacker can do to stop them. A temporary dishonest majority
heals relatively well.

There is another severe disadvantage to this on-chain delegation system:
every UTXO must indicate which staking account this UTXO belongs to so the
appropriate share of block rewards can be transferred there.
Being able to associate every UTXO to an account ruins one of the main
privacy advantages of the UTXO model.
It also grows the size of the blockchain significantly.

### "Pure" proof of stake (Algorand)

Algorand's[4] approach is to only allow online stake to participate in the
protocol.
Theoretically, This means that keys holding funds have to be online in
order for them to author blocks when they are chosen.
Of course in reality no one wants to keep their coin holding keys online so
in Alogorand you can authorize a set of "participation keys"[1] that will
be used to create blocks on your coin holding key's behalf.
Hopefully you've spotted the problem.
You can send your participation keys to any malicious party with a nice
website (see random example [2]) offering you a good return.
Damn it's still Proof-of-SquareSpace!
The minor advantage is that at least the participation keys expire after a
certain amount of time so eventually the SquareSpace attacker will lose
their hold on consensus.
Importantly there is also less junk on the blockchain because the
participation keys are delegated off-chain and so are not making as much of
a mess.

### Conclusion

I don't see a way to get around the conflicting requirement that the keys
for large amounts of coins should be kept offline but those are exactly the
coins we need online to make the scheme secure.
If we allow delegation then we open up a new social attack surface and it
degenerates to Proof-of-SquareSpace.

For a "digital gold" like system like Bitcoin we optimize for simplicity
and desperately want to avoid extraneous responsibilities for the holder of
the coin.
After all, gold is an inert element on the periodic table that doesn't
confer responsibilities on the holder to maintain the quality of all the
ot