* [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
@ 2017-06-19 18:01 Wang Chun
2017-06-19 18:31 ` Peter Todd
2017-06-19 20:32 ` Moral Agent
0 siblings, 2 replies; 3+ messages in thread
From: Wang Chun @ 2017-06-19 18:01 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
There has been proposal to change the PoW in case of potential 51% attacks
from malicious miners during a fork. But such a change in PoW renders
multi-billion-dollar of ASIC into worthless. which hurts economy so much
and the average innocent mining users. I would propose, instead of PoW
change, we could change the system to the same double sha256 PoW but mix it
with PoS features. Such a PoW+PoS system has several advantages:
* It protects existing multi-billion dollar investments from innocent
mining users,
* A malicious miner cannot launch attacks and rewrite the blockchain with
51% or even more hashrate,
* If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block
time span, that solves the long confirmation time problem,
* We'll suddenly have 5 times of block space, that solves the scaling
problem,
* The PoS blocks only mine transaction fees, so the 21M cap remains,
* With careful design, the PoW+PoS transition _might_ be able to deploy
with a soft fork.
[-- Attachment #2: Type: text/html, Size: 1117 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
2017-06-19 18:01 [bitcoin-dev] An alternative way to protect the network from 51% attacks threat Wang Chun
@ 2017-06-19 18:31 ` Peter Todd
2017-06-19 20:32 ` Moral Agent
1 sibling, 0 replies; 3+ messages in thread
From: Peter Todd @ 2017-06-19 18:31 UTC (permalink / raw)
To: Wang Chun; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]
On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote:
> There has been proposal to change the PoW in case of potential 51% attacks
> from malicious miners during a fork. But such a change in PoW renders
> multi-billion-dollar of ASIC into worthless. which hurts economy so much
> and the average innocent mining users. I would propose, instead of PoW
> change, we could change the system to the same double sha256 PoW but mix it
> with PoS features. Such a PoW+PoS system has several advantages:
You have to specify what you mean by "PoS" - there's dozens of variations.
Equally, existing pure PoS schemes probably don't make sense as a "bolt-on"
add-on, as once you introduce PoW to it you should design something that uses
the capabilities of both systems.
FWIW, I've heard that the Ethereum guys are leaning towards abandoning pure PoS
and are now trying to design a PoW + staking system instead.
> * It protects existing multi-billion dollar investments from innocent
> mining users,
To be clear, you mean such a scheme would protect the multi-billion dollar
investments non-malicious miners have made in SHA256^2 hardware by ensuring it
remains useful, right?
> * A malicious miner cannot launch attacks and rewrite the blockchain with
> 51% or even more hashrate,
> * If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block
> time span, that solves the long confirmation time problem,
Note that if those PoS blocks are *pure* PoS, you'll create a significant risk
of double-spend attacks, as there's zero inherent cost to creating a pure-PoS
block. Such blocks can't be relied on for confirmations; even "slasher" schemes
have significant problems with sybil attacks.
> * We'll suddenly have 5 times of block space, that solves the scaling
> problem,
The scaling problem is one of scalability; PoS does nothing to improve
scalability (though many in the ETH community have been making dishonest
statements to the contrary).
> * The PoS blocks only mine transaction fees, so the 21M cap remains,
> * With careful design, the PoW+PoS transition _might_ be able to deploy
> with a soft fork.
As a sidechain yes, but in what you propose above the extra blocks wouldn't
contain transactions that non-PoS-aware nodes could understand in a
backwards-compatible way.
All the above aside, I don't think it's inherently wrong to look at adding PoS
block *approval* mechanisms, where a block isn't considered valid without some
kind of coin owner approval. While pure-PoS is fundamentally broken in a
decentralized setting, it may be possible to mitigate the reasons it's broken
with PoW and get a system that has a stronger security model than PoW alone.
FWIW there's some early discussions by myself and others about this type of
approach on the #bitcoin-wizards IRC channels, IIRC from around 2014 or so.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
2017-06-19 18:01 [bitcoin-dev] An alternative way to protect the network from 51% attacks threat Wang Chun
2017-06-19 18:31 ` Peter Todd
@ 2017-06-19 20:32 ` Moral Agent
1 sibling, 0 replies; 3+ messages in thread
From: Moral Agent @ 2017-06-19 20:32 UTC (permalink / raw)
To: Wang Chun; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4609 bytes --]
Here is the text of a post to reddit from Feb 2017, discussing a similar
idea, and wondering if it could reduce the incentive to delay broadcast of
solved blocks:
# How an anchored Proof of Stake Sidechain can help the Bitcoin main chain
# Steps:
1. Soft fork Bitcoin to enable side chains
2. Create a side chain that is secured with Proof of Stake. Call blocks on
this chain "POS-blocks." The original chain is made of "POW-blocks."
3. Side chain mints one POS-block after each POW-block on the main chain,
and contains the hash of the POW-block, and the hash of the previous
POS-block. See diagram [here.](https://s32.postimg.org/916n9zxlx/Pos_Sf1.png
)
4. Side chain Minters must make a deposit in order to mint. If they mint an
invalid POS-block, they lose the deposit.
5. Side chain blocks are small enough to broadcast and validate quickly
(e.g. 100 - 300 KB).
6. Soft fork a new rule into Bitcoin that encourages POW-blocks to include
the hash of the prior POS-block. Specifically, penalize POW-blocks which do
not point to the prior POS-block by doubling the difficulty necessary for
them to be valid. Call POW-blocks which do not point to the prior POS-block
but are valid because of their very high POW "hard blocks."
In the following diagram POW2 and POW4 are valid because they point to the
prior POS-block and also satisfy the difficulty requirement. POW3 does not
point to the prior POS-bock, but is valid anyway because it contains proof
of work at twice the normal difficulty.
https://s27.postimg.org/6hc0b8ejn/Pos_Sf2.png
# Advantages:
1. Allow people who do not control ASICs to influence which transactions
happen.
2. Allow people who do not control ASICs to influence which chain gets
extended.
3. Reduce the incentive to selfish mine. Once a miner discovers a block,
they should broadcast it immediately in the hopes that a Minter will build
on it, because that is the most likely way their block will not go stale.
Miners will also immediately start trying to build a hard block. (Maybe
statistics could tell us what is the proper range for the Hardness
Multiplier. I guessed 2 would be good.)
4. Reduces the effective block interval while reducing the incidence of
stale blocks, empty blocks and SPV mining. After a POW-block is mined, it
is immediately broadcast to the network, seeking a qualified Minter to
extend it. Minters have a deposit, which they will lose if they mint an
invalid block. Pointing to the hash of an invalid POW-block would produce
an invalid minted block, so Minters have a strong incentive to completely
validate the POW-block before they mint on top of it. After validating,
they mint a block and broadcast it. While the Minter is validating the
previous POW-block, competing miners also have time to fully validate the
previous POW-block. By the time the Miners receive the POS-block, they know
what transactions they can and cannot include in their own block, because
the Minter only processes transactions on the side chain. There is less
reason to mine empty blocks, because there is adequate time to update the
mempool before mining the next soft block begins, and because hard blocks
take a long time to produce. The risks involved with mining on an
un-validated POS-block can be made small by the fact that there is a
deposit that will be destroyed if the POS-block is invalid. POS-blocks can
be validated quickly because they are small.
Here is a gantt chart of the schedule described above:
https://s22.postimg.org/hvnkyac5d/Pos_Sf3.png
5. Unlike a pure POS system, a cabal of early Stake holders cannot cheaply
hatch an alternate history. Much less imperative for nodes to go to a
trusted peer and ask whether the chain they are being fed is legitimate.
6. After step 6 above, the side chain would have essentially the same
security characteristics as the main chain, and could be used
interchangeably.
7. No hard fork required, and this soft fork could be deployed even if the
miners do not consent to it. Some hybrid POS system would be my
recommendation as preferable to simply changing POW algorithms in the face
of miners abusing their power.
8. Users can opt into the POS sidechain, and it can fully prove itself in
production before there is any attempt to anchor the main chain back to it.
Even if consensus cannot be obtained to execute step 6, the mere existence
of such a chain could deter tomfoolery on the part of POW miners, lest they
galvanize the community into throwing the switch.
Original reddit post here:
https://www.reddit.com/r/Bitcoin/comments/5vy4qc/how_an_anchored_proof_of_stake_sidechain_can_help/
[-- Attachment #2: Type: text/html, Size: 5640 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-06-19 20:32 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-19 18:01 [bitcoin-dev] An alternative way to protect the network from 51% attacks threat Wang Chun
2017-06-19 18:31 ` Peter Todd
2017-06-19 20:32 ` Moral Agent
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox