Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[ZmnSCPxj via bitcoin-dev]

Good morning all,

> > >>>Under the trust-minimization requirement of Bitcoin this is simply not 
> > >>>acceptable.
> > As there is no way to trust-minimally heal from a network split (and every 
> > time a node is shut down, that is indistinguishable from a network split 
> > that isolates that particular node), this is not a trust-minimizing 
> > consensus algorithm.
>
> That’s nonsense, one is a feature (systemic trust), the other is a bug (code 
> accident). But there is a way to minimize actual forks - try not to change 
> the consensus rules in the code you ship.

I am uncertain what you mean here.

What I am attempting to compare are:

1.  A network split (maybe better term is "network partition"?) wherein some 
number of nodes are temporarily unable to contact the rest of the network.
This has the degenerate but very common case where a single node is 
temporarily unable to communicate with the rest of the network.

AND

2.  A node being shut down, then brought back online again.

Neither seems to match "feature" or "bug", as both are simply accidents of 
deployment.

The point (as I understand it) of a consensus algorithm is to be able to get 
all nodes into agreement about the global state, even after a network partition.
Ideally, such an algorithm would place as little trust as possible on some 
other node, and would work even in adversarial conditions.

To my understanding, the proposal from Kenshiro is not able to get all nodes 
into agreement about global state after a network partition, without trust in 
some node, when in adversarial conditions.


> > >>> History rewrites are not the only attack possible.
> > The worst attack is a censorship attack, and a 99% staker can easily censor 
> > on the creation of new blocks.
> >
> > I don't agree, history rewrite attacks are much worse than censorship 
> > because they can be used to steal funds from people.
>
> Censorship can steal everybody’s money.

To expand on this: by censoring ***all*** transactions one is able to prevent 
spending of all funds.
This will crash the value of the staked funds also, but note that the staker 
could use techniques like short options to leverage this and potentially earn 
more than the value of their staked funds, effectively stealing the entire 
marketcap of the attacked coin.


>
> > In PoS staking addresses are public, so maybe it should be possible to 
> > detect if some transaction in the mempool is repeatedly being ignored and 
> > what staking deposit is repeatedly ignoring transactions. After some time, 
> > a hard fork could burn the funds of the evil validator.
>
> Political money.

Aside from that, this is possible to evade by running 1 masternodes and 
splitting your staking funds among them.
Rent from a botnet, and it appears the masternodes are geographically diverse.
Then it becomes hard to accuse the network of actually being controlled 
strongly by a single participant.
(the ability to rent botnets means that even existing PoS coins might already 
be strongly controlled, but appear "healthy" because masternodes *appear* 
geographically diverse, but in actuality are controlled by a single entity)

Further, "detect if some transaction in the mempool" cannot provide a proof, as 
no construct ever precommits to the state of the mempool at a particular time 
(if it did, the mempool would cease to be a mempool and would be part of the 
block).
I can generate a completely new transaction, then accuse the masternodes of 
censoring it.
Other nodes may not believe me, as they have not seen my transaction on their 
mempool, but note that the mempools of nodes are ***not*** strongly 
synchronized.
By careful timing and control of the connectivity of the network, it becomes 
possible to effectively split the consensus algorithm by showing my transaction 
to some non-masternode nodes but keeping my transaction away from masternodes, 
then have the non-masternode nodes accuse the masternodes of censoring my 
transaction and hereby penalizing them.
But the masternodes would not agree, not having seen my transaction in their 
mempool, and thus is the network consensus destroyed.

Basically: "never base consensus rules on mempool state" is a good rule of 
thumb for ensuring that consensus can be maintained.
Consensus rules should consider only data that is committed to some block, and 
the mempool is not intended to be committed to in every block.


> > https://www.coingecko.com/en/coins/nxt
> >
> > Another thing is that Ethereum itself is going to PoS next year, but with a 
> > different implementation that I'm proposing here.
>
> Just another nail in the coffin.

I agree.



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

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[Eric Voskuil via bitcoin-dev]

> On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev 
>  wrote:
> 
> Hi ZmnSCPxj,
> 
> I'm based on the more evolved implementation of PoS that I know, which is PoS 
> v3.0 and it's currently implemented in several coins:
> 
> http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version
> 
> As far as I know the grinding attack is and old issue that is fixed in PoS 
> v3.0.
> 
> >>>At least the proposed `assumeutxo` requires the operator to explicitly 
> >>>enable it, but I believe your "hardcoded checkpoints" cannot be disabled, 
> >>>much less disabled-by-default.
> 
> We don't trust the developers, the source code is public and anyone can check 
> it. With the hardcoded checkpoints is exactly the same, they are in the 
> source code repository and everyone can check them. The checkpoints are the 
> easiest part to check. A user doesn't have any reason to remove the 
> checkpoints, but as with anything in the source code, they could modify it to 
> avoid the checkpoints (and become vulnerable to Long Range attacks doing it)

Bad precedent set by Bitcoin, just like retroactively hardcoding soft fork 
activation checkpoints.

> >>>Under the trust-minimization requirement of Bitcoin this is simply not 
> >>>acceptable.
> As there is no way to trust-minimally heal from a network split (and every 
> time a node is shut down, that is indistinguishable from a network split that 
> isolates that particular node), this is not a trust-minimizing consensus 
> algorithm.

That’s nonsense, one is a feature (systemic trust), the other is a bug (code 
accident). But there is a way to minimize actual forks - try not to change the 
consensus rules in the code you ship.

> The block explorer or other additional source of trust like a friend would 
> only be required in the extreme situation that the network is under a 51% 
> attack, and only by the nodes that are updating blocks in that moment. 
> Updated nodes are fully protected, and under normal circumstances new nodes 
> can just follow the longest chain as always. The other extreme situation that 
> could cause a hard fork is that the network is splitted more than N blocks, 
> which should require some social consensus to fix it. So N should be long 
> enough, like a few hours of blocks or even 1 day.

Consensus rules are the social consensus. If you have an objective way to do 
this, write the rule.

> >>> History rewrites are not the only attack possible.
> The worst attack is a censorship attack, and a 99% staker can easily censor 
> on the creation of new blocks.
> 
> I don't agree, history rewrite attacks are much worse than censorship because 
> they can be used to steal funds from people.

Censorship can steal everybody’s money.

> In PoS staking addresses are public, so maybe it should be possible to detect 
> if some transaction in the mempool is repeatedly being ignored and what 
> staking deposit is repeatedly ignoring transactions. After some time, a hard 
> fork could burn the funds of the evil validator.

Political money.

> >>> Worse, under proof-of-stake it is often the case that stakers are awarded 
> >>> even more coin with which they can stake.
> 
> Sure, but in PoW the miners with more hash power earn more coins that can be 
> used to purchase more miners.

True, but this is at least limited proportionally.

> There is always the privilege of the rich guy, no matter if its PoW or PoS. 
> The point is to design a protocol that don't allow the rich to destroy the 
> network.

The ability to introduce new power to the chain is the only way to evict a 
censor. In PoS a well capitalized individual or state can buy total control 
over the system forever at no ongoing cost. PoW allows any number of 
individuals to pay higher fees on censored txs and evict the censor, who must 
then maintain the cost of subsidizing censorship.

> Let me put it in this way: NXT is a PoS coin that uses moving checkpoints 
> with a market cap of 21 million dollars. If the current PoS protocols are so 
> flawed, how can you explain that a coin with this market cap is not being 
> attacked?

The state doesn’t care because there is no material impact from it? It hasn’t 
started attacking Bitcoin yet either.

> https://www.coingecko.com/en/coins/nxt
> 
> Another thing is that Ethereum itself is going to PoS next year, but with a 
> different implementation that I'm proposing here.

Just another nail in the coffin.

Best,
Eric

> Regards,
> 
>  
> From: ZmnSCPxj 
> Sent: Wednesday, July 17, 2019 1:00
> To: Kenshiro \[\]; Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
>  
> Good morning Kenshiro,
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev 
>  wrote:
> 
> > Hi,
> >
> > After studying several Proof of Stake implementations I think it's not only 
> > an eco-friendly (and more ethical) 

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[Kenshiro [] via bitcoin-dev]

Hi ZmnSCPxj,

I'm based on the more evolved implementation of PoS that I know, which is PoS 
v3.0 and it's currently implemented in several coins:

http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version

As far as I know the grinding attack is and old issue that is fixed in PoS v3.0.

>>>At least the proposed `assumeutxo` requires the operator to explicitly 
>>>enable it, but I believe your "hardcoded checkpoints" cannot be disabled, 
>>>much less disabled-by-default.

We don't trust the developers, the source code is public and anyone can check 
it. With the hardcoded checkpoints is exactly the same, they are in the source 
code repository and everyone can check them. The checkpoints are the easiest 
part to check. A user doesn't have any reason to remove the checkpoints, but as 
with anything in the source code, they could modify it to avoid the checkpoints 
(and become vulnerable to Long Range attacks doing it)

>>>Under the trust-minimization requirement of Bitcoin this is simply not 
>>>acceptable.
As there is no way to trust-minimally heal from a network split (and every time 
a node is shut down, that is indistinguishable from a network split that 
isolates that particular node), this is not a trust-minimizing consensus 
algorithm.

The block explorer or other additional source of trust like a friend would only 
be required in the extreme situation that the network is under a 51% attack, 
and only by the nodes that are updating blocks in that moment. Updated nodes 
are fully protected, and under normal circumstances new nodes can just follow 
the longest chain as always. The other extreme situation that could cause a 
hard fork is that the network is splitted more than N blocks, which should 
require some social consensus to fix it. So N should be long enough, like a few 
hours of blocks or even 1 day.

>>> History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor on 
the creation of new blocks.

I don't agree, history rewrite attacks are much worse than censorship because 
they can be used to steal funds from people. In PoS staking addresses are 
public, so maybe it should be possible to detect if some transaction in the 
mempool is repeatedly being ignored and what staking deposit is repeatedly 
ignoring transactions. After some time, a hard fork could burn the funds of the 
evil validator.

>>> Worse, under proof-of-stake it is often the case that stakers are awarded 
>>> even more coin with which they can stake.

Sure, but in PoW the miners with more hash power earn more coins that can be 
used to purchase more miners. There is always the privilege of the rich guy, no 
matter if its PoW or PoS. The point is to design a protocol that don't allow 
the rich to destroy the network.


Let me put it in this way: NXT is a PoS coin that uses moving checkpoints with 
a market cap of 21 million dollars. If the current PoS protocols are so flawed, 
how can you explain that a coin with this market cap is not being attacked?

https://www.coingecko.com/en/coins/nxt

Another thing is that Ethereum itself is going to PoS next year, but with a 
different implementation that I'm proposing here.

Regards,


From: ZmnSCPxj 
Sent: Wednesday, July 17, 2019 1:00
To: Kenshiro \[\]; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

Good morning Kenshiro,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev 
 wrote:

> Hi,
>
> After studying several Proof of Stake implementations I think it's not only 
> an eco-friendly (and more ethical) alternative to Proof of Work, but 
> correctly implemented could be 100% secure against all 51% history rewrite 
> attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra 
> improvements are required:

Under the trust-minimization and uncensorability requirements that Bitcoin has, 
nothing is more efficient than proof-of-work.
The very idea of proof-of-stake labors under the assumption that unencumbered 
free-market payment for the consumption of energy is somehow not 
market-efficient despite the well-known phenomenon of the invisible hand, and 
believes that it is possible to get something for nothing.

Please re-examine your assumptions.

> - Hardcoded checkpoints:each Bitcoin Core release (each few months) should 
> include a hardcoded checkpoint with the hash of the current block height in 
> that moment. This simple measure protects the blockchain up to the last 
> checkpoint, and prevents any Long-Range attack.

While this is a developer list and made up of developers who would be quite 
incentivized to agree to such a setup, note that this effectively trusts the 
developers.
At least the proposed `assumeutxo` requires the operator to explicitly enable 
it, but I believe your "hardcoded checkpoints" 

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[ZmnSCPxj via bitcoin-dev]

Good morning Kenshiro,

> 4 - In any given block, only one staker gets the authorization to create that 
> block, so other stakers can't spam the network with many different blocks as 
> they are illegal. 

This leaves the consensus algorithm liable to stake-grinding attacks.
Often, the selection of the "single staker" for each block is based on some 
hashing of some number of the previous headers.

This allows the single staker to do some trivial grinding of the `R` of some 
signature of some transaction of some money from itself to itself.
This grinding is likely to change the hash of the current block.
Changing the hash of the current block is enough to change the hash that is 
used in the selection of the **next** single staker.
Note that the staker will of course only publish the version of that block that 
makes itself the **next** staker.

This is the well-known stake-grinding attack; did you not encounter it in your 
proof-of-stake research?
This is a basic objection to proof-of-stake, together with the nothing-at-stake.

Suppose the staker owns 49% of the staked funds.
It is now trivial for it to continuously grind so that it is again the next 
staker for the next block, as 49% of the time, it would be selected as the next 
staker.
Further, this is easily hideable, as the staker can simply run 10 
masternodes and split its funds to all of them, so that it becomes very 
non-obvious that there is in fact only one staker running the entire network.

(Did you consider how much energy such a staker would be willing to spend on 
grinding so that it remains the next staker forevermore?
In particular, the staker would be willing to spend energy up to the block 
reward in such grinding --- a property that proof-of-work has, and ***openly*** 
admits it has.)

In particular, this allows that one staker to impose any censorship it likes.
Thus, Bitcoin cannot support any kind of proof-of-stake that is vulnerable to 
this stake-grinding attack.

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

[bitcoin-dev] BIP: Signet

[Karl-Johan Alm via bitcoin-dev]

Hello,

I have written a BIP describing the Signet network. Feedback requested!

https://github.com/bitcoin/bips/pull/803

Pasted in its entirety below, with formatting issues left as is. See
above link for styled version.


BIP: 
Layer: Applications
Title: Signet
Author: Karl-Johan Alm 
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-
Status: Draft
Type: Standards Track
Created: 2019-03-20
License: CC0-1.0


== Abstract ==

A new type of test network where signatures are used in addition to
proof of work for block progress, enabling much better coordination
and robustness (be reliably unreliable), for persistent, longer-term
testing scenarios involving multiple independent parties.

== Motivation ==

Testnet is a great place to try out new things without risking real
money, but it is notoriously unreliable. Huge block reorgs, long gaps
in between blocks being mined or sudden bursts of blocks in rapid
succession mean that realistic testing of software, especially
involving multiple independent parties running software over an
extended period of time, becomes infeasible in practice.

A new type of test network would be more suitable for integration
testing by organizations such as exchanges, or testing of next
generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is
not to be perfectly reliable but rather to have a predictable amount
of unreliability. You want a test network to behave like mainnet (i.e.
no thousands of block reorgs) while also making it easier to trigger
expected but rare events like a 6-block reorg. Regtest is not suitable
for longer-term scenarios involving multiple independent parties
because creating blocks costs nothing, so any party can completely
control the test network.


== Specification ==

A new type of network ("signet"), which takes an additional consensus
parameter called the challenge (scriptPubKey). The challenge can be a
simple pubkey (P2PKH style), or a k-of-n multisig, or any other script
you would want.

The witness commitment of the coinbase transaction is extended to
include a secondary commitment (the signature/solution):

1-4 bytes - Push the following (x + 4) bytes
4 bytes - Signet header (0xecc7daa2)
x bytes - Solution (sigScript)

Any push operations that do not start with the 4 byte signet header
are ignored. Multiple push operations with the 4 byte signet header
are ignored except for the first entry.

Any signature operations contained within the challenge use
SHA256d(modifiedBlockHash), i.e. the double-SHA256 digest of the
following data as the sighash:

{|class="wikitable" style="text-align: center;"
|-
!Type
!Size
!Name
|-
|Int32||4||nVersion
|-
|Uint256||32||hashPrevBlock
|-
|Uint256||32||modifiedMerkleRoot
|-
|Uint32||4||nTime
|-
|Uint32||4||nBits
|}

The modifiedMerkleRoot hash is obtained by generating the
merkle root of the block transactions, with the coinbase witness
commitment as is, without the signet extension. This means the merkle
root of the block is different from the merkle root in the signet
commitment, but in return, the block nonce value is the only component
that the signet signature does not commit to. When grinding proof of
work, the extended nonce cannot be used as it would invalidate the
signature. Instead, simply resigning the same (or an updated) block
will give a new search space.

A block is considered fully validated if the above commitment is
found, and its solution is valid. This verification should be done
directly before or after the witness commitment verification.

== Compatibility ==

This specification is backwards compatible in the sense that existing
software can use Signet out of the box.

Simply by adding the network parameters for signet (magic number,
etc), a client can connect to and use any signet network without
further modifications. The block headers have valid proof of work, so
clients can trivially check that blocks are "probably" valid.

However, anyone can mine blocks that are accepted by the client for
any given signet network. These blocks do not contain the required
signatures, however, so any fully validating node will promptly reject
them. As such, clients need to either validate the block signature
inside the coinbase transaction, or connect to trusted peers.

Other software need not add block signature validation code that they
will not use in production. This is adequate for non-production test
purposes where the goal is to have a network behave as much like
mainnet as possible.

== Reference implementation ==

WIP implementation at https://github.com/kallewoof/bitcoin/pull/4

== Acknowledgements ==

TODO

== References ==

# Original mailing list thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
# Bitcoin Wiki entry: https://en.bitcoin.it/wiki/Signet

== Copyright ==

This document is licensed under the Creative Commons CC0 1.0 Universal license.

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[ZmnSCPxj via bitcoin-dev]

Good morning Kenshiro,


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev 
 wrote:

> Hi,
>
> After studying several Proof of Stake implementations I think it's not only 
> an eco-friendly (and more ethical) alternative to Proof of Work, but 
> correctly implemented could be 100% secure against all 51% history rewrite 
> attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra 
> improvements are required:

Under the trust-minimization and uncensorability requirements that Bitcoin has, 
nothing is more efficient than proof-of-work.
The very idea of proof-of-stake labors under the assumption that unencumbered 
free-market payment for the consumption of energy is somehow not 
market-efficient despite the well-known phenomenon of the invisible hand, and 
believes that it is possible to get something for nothing.

Please re-examine your assumptions.

> - Hardcoded checkpoints:each Bitcoin Core release (each few months) should 
> include a hardcoded checkpoint with the hash of the current block height in 
> that moment. This simple measure protects the blockchain up to the last 
> checkpoint, and prevents any Long-Range attack.

While this is a developer list and made up of developers who would be quite 
incentivized to agree to such a setup, note that this effectively trusts the 
developers.
At least the proposed `assumeutxo` requires the operator to explicitly enable 
it, but I believe your "hardcoded checkpoints" cannot be disabled, much less 
disabled-by-default.

> This extra rule could be connecting to a block explorer to download the hash 
> of the current block height, or ask some trusted source like a friend and 
> enter the hash manually. After being fully updated, the user can always check 
> that he is in the correct chain checking with a block explorer.

Under the trust-minimization requirement of Bitcoin this is simply not 
acceptable.
As there is no way to trust-minimally heal from a network split (and every time 
a node is shut down, that is indistinguishable from a network split that 
isolates that particular node), this is not a trust-minimizing consensus 
algorithm.

>
> Someone could have 99% of the coins and still would be unable to use the 
> coins to do any history rewrite attack. The attacker could only slow down the 
> network not creating his blocks, or censor transactions in his blocks.

History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor on 
the creation of new blocks.

Censorship attacks cannot be prevented except by ensuring that no single entity 
can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlikely 
to keep a transaction out of the blockchain, and in particular that no entity 
can make a short-ranged history rewrite if a censored transaction *does* get 
into the blockchain from the efforts of another block producer.

This is trivial under proof-of-work, and is the cost we accept in order to 
achieve uncensorability, since it is non-trivial to acquire energy.
Under proof-of-stake it is difficult to impossible to determine if some single 
entity controls >51% of stakeable coins, and thus has no way to protect against 
censorship attack.
Worse, under proof-of-stake it is often the case that stakers are awarded even 
more coin with which they can stake.

Depending on the PoS implementation, stake-grinding may allow a 49% staker to 
achieve 51% and thereby the ability to censor transactions.


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

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[Kenshiro [] via bitcoin-dev]

Hi Oscar,

Thank you for your answer. Just to clarify my proposal:

1 - It's a full change to Proof of Stake protocol to avoid the energy waste and 
to prevent a 51% history rewrite attack, even if the attacker has 99% of coins.

2 - The hardcoded checkpoints could be set by each bitcoin node client, not 
only Bitcoin Core. No matter if the checkpoints are different, only that they 
are frequent. They are there to prevent Long Range attacks. Checkpoints are 
public just like the rest of the software, they don't require any trust. A bad 
checkpoint would be detected by the community.

3 - There are several PoS coins working just now and as far as I know they 
don't have any problem. NXT coin implements the moving checkpoint system and 
others the hardcoded checkpoints.

4 - In any given block, only one staker gets the authorization to create that 
block, so other stakers can't spam the network with many different blocks as 
they are illegal.

5 - The block explorer is only required during a 51% attack, and only for nodes 
that are updating blocks during the attack. Updated nodes are protected thanks 
to the moving checkpoints.

Regards,


From: Oscar Lafarga 
Sent: Tuesday, July 16, 2019 22:35
To: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

Hi Kenshiro,

I don't think your proposal would require any changes to the Bitcoin Core 
implementation. This system you describe seems like it would operate as an 
independent addition, rather than an alternative to the Proof of Work consensus 
code that runs within Bitcoin now. It introduces security risk in the selection 
of block explorer and to the Bitcoin Core release dispatch system, reducing the 
trustlessness of the current network. Also, without the constraints that PoW 
places on block creation, you increase the vector space for attacks since it is 
trivial to spam blocks to node on the network (see Sybil 
attack).

I believe many other software projects have tried similar checkpointing schemes 
that have resulted in hard forks or overall weakened consensus. I haven't dug 
too deeply, but I'm not aware of any cases where these schemes accomplish 
anything useful to improve the bitcoin network.

Best,

On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev 
mailto:bitcoin-dev@lists.linuxfoundation.org>>
 wrote:

Hi,


After studying several Proof of Stake implementations I think it's not only an 
eco-friendly (and more ethical) alternative to Proof of Work, but correctly 
implemented could be 100% secure against all 51% history rewrite attacks. Over 
a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required:


- Hardcoded checkpoints: each Bitcoin Core release (each few months) should 
include a hardcoded checkpoint with the hash of the current block height in 
that moment. This simple measure protects the blockchain up to the last 
checkpoint, and prevents any Long-Range attack.


- Moving checkpoints: the nodes only allow chain reorgs not deeper than N 
blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at any 
block under nodeBlockHeight - N. This fully protects nodes that are online and 
updated. Nodes that are not fully updated need some extra rule to be protected 
between the last hardcoded checkpoint and the current blockchain height. This 
extra rule could be connecting to a block explorer to download the hash of the 
current block height, or ask some trusted source like a friend and enter the 
hash manually. After being fully updated, the user can always check that he is 
in the correct chain checking with a block explorer.


Someone could have 99% of the coins and still would be unable to use the coins 
to do any history rewrite attack. The attacker could only slow down the network 
not creating his blocks, or censor transactions in his blocks.


What do you think? :)


Regards

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


--
Oscar Lafarga
https://www.setlife.network

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

Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

[Oscar Lafarga via bitcoin-dev]

Hi Kenshiro,

I don't think your proposal would require any changes to the Bitcoin Core
implementation. This system you describe seems like it would operate as an
independent addition, rather than an alternative to the Proof of Work
consensus code that runs within Bitcoin now. It introduces security risk in
the selection of block explorer and to the Bitcoin Core release dispatch
system, reducing the trustlessness of the current network. Also, without
the constraints that PoW places on block creation, you increase the vector
space for attacks since it is trivial to spam blocks to node on the network
(see Sybil attack ).

I believe many other software projects have tried similar checkpointing
schemes that have resulted in hard forks or overall weakened consensus. I
haven't dug too deeply, but I'm not aware of any cases where these schemes
accomplish anything useful to improve the bitcoin network.

Best,

On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
>
> After studying several Proof of Stake implementations I think it's not
> only an eco-friendly (and more ethical) alternative to Proof of Work, but
> correctly implemented could be 100% secure against all 51% history rewrite
> attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra
> improvements are required:
>
>
> - Hardcoded checkpoints: each Bitcoin Core release (each few months)
> should include a hardcoded checkpoint with the hash of the current block
> height in that moment. This simple measure protects the blockchain up to
> the last checkpoint, and prevents any Long-Range attack.
>
>
> - Moving checkpoints: the nodes only allow chain reorgs not deeper than N
> blocks. If N is 10 blocks, then the nodes ignore any hard fork starting at
> any block under nodeBlockHeight - N. This fully protects nodes that are
> online and updated. Nodes that are not fully updated need some extra rule
> to be protected between the last hardcoded checkpoint and the current
> blockchain height. This extra rule could be connecting to a block explorer
> to download the hash of the current block height, or ask some trusted
> source like a friend and enter the hash manually. After being fully
> updated, the user can always check that he is in the correct chain checking
> with a block explorer.
>
>
> Someone could have 99% of the coins and still would be unable to use the
> coins to do any history rewrite attack. The attacker could only slow down
> the network not creating his blocks, or censor transactions in his blocks.
>
>
> What do you think? :)
>
>
> Regards
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 
Oscar Lafarga
https://www.setlife.network

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