* [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
@ 2017-03-24 16:03 CANNON
2017-03-24 16:27 ` Emin Gün Sirer
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: CANNON @ 2017-03-24 16:03 UTC (permalink / raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
When the original white paper was written the idea was that nodes
would be miners at same time. That the distribution of mining power
being mostly on par with the distribution of nodes if I understand
correctly. The problem we face now I fear, is the mining power
becoming centralized. Even if every bitcoin node invested a $1000
into mining power and mined at a loss, it still would not even
make a dent in hash distribution. Currently there are around 6000
known nodes. If each node invested $1000 for say 10 ths of hashing
power. At current hashrate of around 3,674,473,142 GH/s this would
only make up %16 of hash power. This is out of balance as while
nodes are distributed mining power is becoming very centralized
due to the creation of monopolization of ASICs. The problem we
are facing is a small group of a couple people whom control a
large amount and growing of hash power. At time of this writing
it has quickly risen to 39% and at current rate will soon become
50% of hashing power that is controlled by a small group of a few
people. Their intentions are too hijack the bitcoin network to a
cryptocurrency that suits their dangerous agenda. Dangerous because
their plan would centralize power of consensus as I understand it,
to themselves the miners. Dangerous also because the code base of
the attempting subverters is buggy, insecure, and reckless from a
technological standpoint. Even though they only have very minute
amount of nodes compared to legitimate bitcion nodes, the danger
is that they are very quickly taking over in mining power. While
it is true that nodes will not accept invalid blocks that would be
attempted to be pushed by the conspirators, they are threatening to
attack the valid (or in their words, "minority chain") by dedicating
some mining power soley to attacking the valid chain by mining empty
blocks and orphaning the valid chain. So even though the majority
of nodes would be enforcing what blocks are valid and as a result
block the non-compliant longer chain, the conspiring miner can simply
(as they are currently threatening to) make the valid chain unuseable
by mining empty blocks.
If a malicious miner with half or majority control passes invalid
blocks, the worst case scenario is a hardfork coin split in which
the non-compliant chain becomes an alt. However the problem is that
this malicious miner is very recently threatening to not just simply
fork, but to kill the valid chain to force economic activity to the
adversary controlled chain. If we can simply defend against attacks
to the valid chain, we can prevent the valid chain from dying.
While empty or near empty blocks would generally be protected by
the incentive of miners to make money. The threat is there if the
malicious miner with majority control is willing to lose out on
these transaction fees and block reward if their intention is to
suppress it to force the majority onto their chain.
Proposal for potential solution Update nodes to ignore empty blocks,
so this way mined empty blocks cannot be used to DOS attack the
blockchain. But what about defense from say, blocks that are
not empty but intentionally only have a couple transactions
in it? Possible to have nodes not only ignore empty blocks,
but also blocks that are abnormally small compared to number of
valid transactions in mempool?
For example would be something like this:
If block = (empty OR <%75 of mempool) THEN discard
This threshold just an example.
What would be any potentials risks
and attacks resulting from both having such new rulesets and not
doing anything?
Lets assume that the first problem of blocking empty or near empty
blocks has been mitigated with the above proposed solution. How
likely and possible would it be for a malicious miner with lots of
mining power to orphan the chain after so many blocks even with
non empty blocks? Is there a need to mitigate this?
If so is it possible?
Time is running short I fear. There needs to be discussion on various
attacks and how they can be guarded against along with various
other contingency plans.
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon@cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
Gu3oWoE1ld+BC6At28AD
=SSuj
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 16:03 [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON
@ 2017-03-24 16:27 ` Emin Gün Sirer
2017-04-14 2:22 ` CANNON
2017-03-24 17:29 ` Nick ODell
` (2 subsequent siblings)
3 siblings, 1 reply; 22+ messages in thread
From: Emin Gün Sirer @ 2017-03-24 16:27 UTC (permalink / raw)
To: Bitcoin Dev, CANNON
[-- Attachment #1: Type: text/plain, Size: 6223 bytes --]
Because there's no consensus on the contents of the mempool, this approach
is unsafe and will lead to forks. It also opens a new attack vector where
people can time the flood of new transactions with the discovery of a block
by a competitor, to orphan the block and to fork the chain.
The technical defense against an attacking majority of miners is to change
the PoW, effectively moving the community off into a new altcoin where the
attackers, hopefully, don't have majority hash power.
- egs
Sent from my phone, please compensate for autocorrect errors.
On Mar 24, 2017 9:06 AM, "CANNON via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon@cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
> Gu3oWoE1ld+BC6At28AD
> =SSuj
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7387 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 16:03 [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON
2017-03-24 16:27 ` Emin Gün Sirer
@ 2017-03-24 17:29 ` Nick ODell
2017-03-24 17:37 ` Hampus Sjöberg
2017-03-24 19:00 ` Aymeric Vitte
2017-03-24 19:00 ` [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? Aymeric Vitte
3 siblings, 1 reply; 22+ messages in thread
From: Nick ODell @ 2017-03-24 17:29 UTC (permalink / raw)
To: CANNON, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6548 bytes --]
Two concerns:
1) This makes block validity depend on things that aren't in the
blockchain. If you and I have different minrelaytxfee's, we will have
different mempool sizes. Your node will discard a block, but my node will
think it is valid, and our nodes will not come to consensus.
2) This is trivially bypassed. A miner can take some coins they own
already, and create a zero-value transaction that has a scriptPubKey of
OP_1. (i.e. anyone-can-spend.) Then, they create another transaction
spending the first transaction, with an empty scriptSig, and the same
scriptPubKey. They do this over and over until they fill up the block.
The last OP_1 output can be left for the next miner. Since the above
algorithm is deterministic, a merkle tree containing every transaction
except the coinbase can be precomputed. The 'malicious' miners do not need
to store this fake block.
On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon@cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
> Gu3oWoE1ld+BC6At28AD
> =SSuj
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 7633 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 17:29 ` Nick ODell
@ 2017-03-24 17:37 ` Hampus Sjöberg
0 siblings, 0 replies; 22+ messages in thread
From: Hampus Sjöberg @ 2017-03-24 17:37 UTC (permalink / raw)
To: Nick ODell, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7230 bytes --]
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example
I don't think this is a good idea, mempool is different from node to node
and is not a part of the consensus.
Hampus
2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> Two concerns:
>
> 1) This makes block validity depend on things that aren't in the
> blockchain. If you and I have different minrelaytxfee's, we will have
> different mempool sizes. Your node will discard a block, but my node will
> think it is valid, and our nodes will not come to consensus.
>
> 2) This is trivially bypassed. A miner can take some coins they own
> already, and create a zero-value transaction that has a scriptPubKey of
> OP_1. (i.e. anyone-can-spend.) Then, they create another transaction
> spending the first transaction, with an empty scriptSig, and the same
> scriptPubKey. They do this over and over until they fill up the block.
>
> The last OP_1 output can be left for the next miner. Since the above
> algorithm is deterministic, a merkle tree containing every transaction
> except the coinbase can be precomputed. The 'malicious' miners do not need
> to store this fake block.
>
> On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> When the original white paper was written the idea was that nodes
>> would be miners at same time. That the distribution of mining power
>> being mostly on par with the distribution of nodes if I understand
>> correctly. The problem we face now I fear, is the mining power
>> becoming centralized. Even if every bitcoin node invested a $1000
>> into mining power and mined at a loss, it still would not even
>> make a dent in hash distribution. Currently there are around 6000
>> known nodes. If each node invested $1000 for say 10 ths of hashing
>> power. At current hashrate of around 3,674,473,142 GH/s this would
>> only make up %16 of hash power. This is out of balance as while
>> nodes are distributed mining power is becoming very centralized
>> due to the creation of monopolization of ASICs. The problem we
>> are facing is a small group of a couple people whom control a
>> large amount and growing of hash power. At time of this writing
>> it has quickly risen to 39% and at current rate will soon become
>> 50% of hashing power that is controlled by a small group of a few
>> people. Their intentions are too hijack the bitcoin network to a
>> cryptocurrency that suits their dangerous agenda. Dangerous because
>> their plan would centralize power of consensus as I understand it,
>> to themselves the miners. Dangerous also because the code base of
>> the attempting subverters is buggy, insecure, and reckless from a
>> technological standpoint. Even though they only have very minute
>> amount of nodes compared to legitimate bitcion nodes, the danger
>> is that they are very quickly taking over in mining power. While
>> it is true that nodes will not accept invalid blocks that would be
>> attempted to be pushed by the conspirators, they are threatening to
>> attack the valid (or in their words, "minority chain") by dedicating
>> some mining power soley to attacking the valid chain by mining empty
>> blocks and orphaning the valid chain. So even though the majority
>> of nodes would be enforcing what blocks are valid and as a result
>> block the non-compliant longer chain, the conspiring miner can simply
>> (as they are currently threatening to) make the valid chain unuseable
>> by mining empty blocks.
>>
>> If a malicious miner with half or majority control passes invalid
>> blocks, the worst case scenario is a hardfork coin split in which
>> the non-compliant chain becomes an alt. However the problem is that
>> this malicious miner is very recently threatening to not just simply
>> fork, but to kill the valid chain to force economic activity to the
>> adversary controlled chain. If we can simply defend against attacks
>> to the valid chain, we can prevent the valid chain from dying.
>>
>> While empty or near empty blocks would generally be protected by
>> the incentive of miners to make money. The threat is there if the
>> malicious miner with majority control is willing to lose out on
>> these transaction fees and block reward if their intention is to
>> suppress it to force the majority onto their chain.
>>
>> Proposal for potential solution Update nodes to ignore empty blocks,
>> so this way mined empty blocks cannot be used to DOS attack the
>> blockchain. But what about defense from say, blocks that are
>> not empty but intentionally only have a couple transactions
>> in it? Possible to have nodes not only ignore empty blocks,
>> but also blocks that are abnormally small compared to number of
>> valid transactions in mempool?
>>
>> For example would be something like this:
>> If block = (empty OR <%75 of mempool) THEN discard
>> This threshold just an example.
>>
>> What would be any potentials risks
>> and attacks resulting from both having such new rulesets and not
>> doing anything?
>>
>> Lets assume that the first problem of blocking empty or near empty
>> blocks has been mitigated with the above proposed solution. How
>> likely and possible would it be for a malicious miner with lots of
>> mining power to orphan the chain after so many blocks even with
>> non empty blocks? Is there a need to mitigate this?
>> If so is it possible?
>>
>> Time is running short I fear. There needs to be discussion on various
>> attacks and how they can be guarded against along with various
>> other contingency plans.
>>
>> - --
>> Cannon
>> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> Email: cannon@cannon-ciota.info
>>
>> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> If this matters to you, use PGP.
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
>> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
>> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
>> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
>> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
>> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
>> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
>> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
>> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
>> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
>> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
>> Gu3oWoE1ld+BC6At28AD
>> =SSuj
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> 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
>
>
[-- Attachment #2: Type: text/html, Size: 8833 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 16:03 [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON
2017-03-24 16:27 ` Emin Gün Sirer
2017-03-24 17:29 ` Nick ODell
@ 2017-03-24 19:00 ` Aymeric Vitte
2017-03-25 16:12 ` CANNON
2017-03-24 19:00 ` [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? Aymeric Vitte
3 siblings, 1 reply; 22+ messages in thread
From: Aymeric Vitte @ 2017-03-24 19:00 UTC (permalink / raw)
To: CANNON, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7766 bytes --]
Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable timeframe
Unfortunately, this was not a priority at all, maybe because of some
historical consensus between miners and devs, so here we are today, some
miners became crazy, the situation would be much more different if more
full nodes were there
Because, how comes everybody perfectly knows the plans of the conspiring
miners? They were stupid enough to explain very precisely how they will
perform the attack?
If I were them I would in addition setup quite a lot of nodes (which
probably they are planning to do, because anyway they need them for the
new sw), not difficult, not so expensive
Defending against abnormal blocks looks to be a non issue, I suppose
that the btc devs perfectly know how to create a pattern based on
history to detect abnormal blocks (including some strange transactions)
and reject them, but this further depends on the ability of current full
nodes to upgrade, which apparently is not what they do the best
I don't know what "Time is running short I fear" stands for and when 50%
is supposed to be reached
Given that it looks difficult to quickly increase the number of full
nodes, that increasing the mining power by standard means looks too
expensive, useless and not profitable, that a counter attack based on a
new proof of something does not look to be ready, then maybe the btc
folks should ask Bram Cohen (who by some luck is participating to this
list) to resurrect the bitcoin miner Epic Scale which Bittorrent Inc (in
an umpteenth dubious attempt to make money) tried some time ago to
include quietly in utorrent forgetting to ask the authorization of the
selected users, then utorrent users might upgrade (potentially 150 M),
and the resulting mining power might be sufficient, depending on the
incentive for this, which is TBD
Or activate by anticipation proof of space... unlike bitcoin-qt,
utorrent sw is quite good to be intrusive, run in background when you
think you have closed it, run things you don't know, etc, so quite
efficient in this situation
Then if btc folks wants to promote full nodes too, it would not be a bad
idea to put the bitcoin-qt blockchain + chain state in a torrent making
sure it is seeded correctly (there are plenty of academics here, they
can do it and run full nodes too) so people can download it and setup
full nodes (incentive TBD too) assuming they know about upnp/port forwarding
Le 24/03/2017 à 17:03, CANNON via bitcoin-dev a écrit :
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org >
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
[-- Attachment #2: Type: text/html, Size: 9875 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 16:03 [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON
` (2 preceding siblings ...)
2017-03-24 19:00 ` Aymeric Vitte
@ 2017-03-24 19:00 ` Aymeric Vitte
3 siblings, 0 replies; 22+ messages in thread
From: Aymeric Vitte @ 2017-03-24 19:00 UTC (permalink / raw)
To: CANNON, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7766 bytes --]
Since I have been working on crypto currencies/bitcoin, I kept
repeating: btc should make a priority to significantly increase the
ridiculous number of full nodes we have today, design an incentive for
people to run full nodes and design a system for people to setup full
nodes in an acceptable timeframe
Unfortunately, this was not a priority at all, maybe because of some
historical consensus between miners and devs, so here we are today, some
miners became crazy, the situation would be much more different if more
full nodes were there
Because, how comes everybody perfectly knows the plans of the conspiring
miners? They were stupid enough to explain very precisely how they will
perform the attack?
If I were them I would in addition setup quite a lot of nodes (which
probably they are planning to do, because anyway they need them for the
new sw), not difficult, not so expensive
Defending against abnormal blocks looks to be a non issue, I suppose
that the btc devs perfectly know how to create a pattern based on
history to detect abnormal blocks (including some strange transactions)
and reject them, but this further depends on the ability of current full
nodes to upgrade, which apparently is not what they do the best
I don't know what "Time is running short I fear" stands for and when 50%
is supposed to be reached
Given that it looks difficult to quickly increase the number of full
nodes, that increasing the mining power by standard means looks too
expensive, useless and not profitable, that a counter attack based on a
new proof of something does not look to be ready, then maybe the btc
folks should ask Bram Cohen (who by some luck is participating to this
list) to resurrect the bitcoin miner Epic Scale which Bittorrent Inc (in
an umpteenth dubious attempt to make money) tried some time ago to
include quietly in utorrent forgetting to ask the authorization of the
selected users, then utorrent users might upgrade (potentially 150 M),
and the resulting mining power might be sufficient, depending on the
incentive for this, which is TBD
Or activate by anticipation proof of space... unlike bitcoin-qt,
utorrent sw is quite good to be intrusive, run in background when you
think you have closed it, run things you don't know, etc, so quite
efficient in this situation
Then if btc folks wants to promote full nodes too, it would not be a bad
idea to put the bitcoin-qt blockchain + chain state in a torrent making
sure it is seeded correctly (there are plenty of academics here, they
can do it and run full nodes too) so people can download it and setup
full nodes (incentive TBD too) assuming they know about upnp/port forwarding
Le 24/03/2017 à 17:03, CANNON via bitcoin-dev a écrit :
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org >
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
[-- Attachment #2: Type: text/html, Size: 9875 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 19:00 ` Aymeric Vitte
@ 2017-03-25 16:12 ` CANNON
2017-03-25 20:28 ` Peter R
0 siblings, 1 reply; 22+ messages in thread
From: CANNON @ 2017-03-25 16:12 UTC (permalink / raw)
To: Aymeric Vitte, Bitcoin Protocol Discussion
On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
> I don't know what "Time is running short I fear" stands for and when 50%
> is supposed to be reached
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
"Time is running short I fear" stands for and when 50% > is supposed
to be reached
According to current hashrate distribution tracking site coin.dance,
very likely within less than four weeks according to current hashrate
takeover rate.
While a fork is very likely, that I dont really fear because worst
case scenario is that bitcoin still survives and the invalid chain
becomes an alt. My fear is the centralized mining power being used
to attack the valid chain with intentions on killing it. [1]
Shouldn't this 50% attack they are threatening be a concern? If it
is a concern, what options are on the table. If it is not a concern
please enlightent me as to why.
[1] Source:
https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/
Text:
The attack quoted from his article:
https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
[Level 2] Anti-split protection Miners will orphan the
blocks of non-compliant miners prior to the first larger block
to serve as a reminder to upgrade. Simply due to the possibility
of having blocks orphaned, all miners would be motivated to
begin signalling for larger blocks once support definitively
passes 51%. If some miners hold out (e.g., they may not be
paying attention regarding the upgrade), then they will begin
to pay attention after losing approximately $15,000 of revenue
due to an orphaned block.
[Level 3] Anti-split protection In the scenario where Levels
1 and 2 protection fails to entice all non-compliant miners to
upgrade, a small-block minority chain may emerge. To address the
risk of coins being spent on this chain (replay risk), majority
miners will deploy hash power as needed to ensure the minority
chain includes only empty blocks after the forking point. This
can easily be accomplished if the majority miners maintain a
secret chain of empty blocks built off their last empty
block publishing only as much of this chain as necessary
to orphan any non-empty blocks produced on the minority chain.
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon@cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
/T93MuZgmvSCry5MlccA
=R71g
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-25 16:12 ` CANNON
@ 2017-03-25 20:28 ` Peter R
2017-03-26 2:38 ` Alex Morcos
2017-03-26 3:00 ` [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?) Eric Voskuil
0 siblings, 2 replies; 22+ messages in thread
From: Peter R @ 2017-03-25 20:28 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
One of the purported benefits of a soft-forking change (a tightening of the consensus rule set) is the reduced risk of a blockchain split compared to a loosening of the consensus rule set. The way this works is that miners who fail to upgrade to the new tighter ruleset will have their non-compliant blocks orphaned by the hash power majority. This is a strong incentive to upgrade and has historically worked well. If a minority subset of the network didn’t want to abide by the new restricted rule set, a reasonable solution would be for them to change the proof-of-work and start a spin-off from the existing Bitcoin ledger (https://bitcointalk.org/index.php?topic=563972.0).
In the case of the coming network upgrade to larger blocks, a primary concern of both business such as Coinbase and Bitpay, and most miners, is the possibility of a blockchain split and the associated confusion, replay risk, etc. By applying techniques that are known to be successful for soft-forking changes, we can likewise benefit in a way that makes a split less likely as we move towards larger blocks. Two proposed techniques to reduce the chances of a split are:
1. That miners begin to orphan the blocks of non-upgraded miners once a super-majority of the network hash power has upgraded. This would serve as an expensive-to-ignore reminder to upgrade.
2. That, in the case where a minority branch emerges (unlikely IMO), majority miners would continually re-org that minority branch with empty blocks to prevent transactions from confirming, thereby eliminating replay risk.
Just like after a soft forking change, a minority that does not want to abide by the current ruleset enforced by the majority could change the proof-of-work and start a spin-off from the existing Bitcoin ledger, as suggested by Emin.
Best regards,
Peter R
> On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> I don't know what "Time is running short I fear" stands for and when 50%
>> is supposed to be reached
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> "Time is running short I fear" stands for and when 50% > is supposed
> to be reached
>
> According to current hashrate distribution tracking site coin.dance,
> very likely within less than four weeks according to current hashrate
> takeover rate.
>
> While a fork is very likely, that I dont really fear because worst
> case scenario is that bitcoin still survives and the invalid chain
> becomes an alt. My fear is the centralized mining power being used
> to attack the valid chain with intentions on killing it. [1]
>
> Shouldn't this 50% attack they are threatening be a concern? If it
> is a concern, what options are on the table. If it is not a concern
> please enlightent me as to why.
>
>
> [1] Source:
> https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/
>
> Text:
>
> The attack quoted from his article:
> https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>
> [Level 2] Anti-split protection Miners will orphan the
> blocks of non-compliant miners prior to the first larger block
> to serve as a reminder to upgrade. Simply due to the possibility
> of having blocks orphaned, all miners would be motivated to
> begin signalling for larger blocks once support definitively
> passes 51%. If some miners hold out (e.g., they may not be
> paying attention regarding the upgrade), then they will begin
> to pay attention after losing approximately $15,000 of revenue
> due to an orphaned block.
>
> [Level 3] Anti-split protection In the scenario where Levels
> 1 and 2 protection fails to entice all non-compliant miners to
> upgrade, a small-block minority chain may emerge. To address the
> risk of coins being spent on this chain (replay risk), majority
> miners will deploy hash power as needed to ensure the minority
> chain includes only empty blocks after the forking point. This
> can easily be accomplished if the majority miners maintain a
> secret chain of empty blocks built off their last empty
> block publishing only as much of this chain as necessary
> to orphan any non-empty blocks produced on the minority chain.
>
>
>
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon@cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> /T93MuZgmvSCry5MlccA
> =R71g
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-25 20:28 ` Peter R
@ 2017-03-26 2:38 ` Alex Morcos
2017-03-26 9:13 ` Chris Pacia
2017-03-26 19:05 ` Peter R
2017-03-26 3:00 ` [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?) Eric Voskuil
1 sibling, 2 replies; 22+ messages in thread
From: Alex Morcos @ 2017-03-26 2:38 UTC (permalink / raw)
To: Peter R, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 7704 bytes --]
Surely you are aware that what you are proposing is vastly different from
the way soft forks have historically worked.
First of all, the bar for miners being on the new chain is extremely high,
95%.
Second of all, soft forks make rule restrictions on classes of transactions
that are already non-standard so that any non-upgraded miners are unlikely
to be including txs in their blocks which would violate the new rules and
should not have their blocks orphaned even after the fork.
Finally, soft forks are designed to only be used when there is a very wide
community consensus and the intention is not to overrule anyone's choice to
remain on the old rules but to ensure the security of nodes that may have
neglected to upgrade. Obviously it is impossible to draw a bright line
between users who intentionally are not upgrading due to opposition and
users that are just being lazy. But in the case of a proposed BU hard fork
it is abundantly clear that there is a very significant fraction, in fact
likely a majority of users who intentionally want to remain on the old
rules.
As a Bitcoin user I find it abhorrent the way you are proposing to
intentionally cripple the chain and rules I want to use instead of just
peacefully splitting.
On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> One of the purported benefits of a soft-forking change (a tightening of
> the consensus rule set) is the reduced risk of a blockchain split compared
> to a loosening of the consensus rule set. The way this works is that
> miners who fail to upgrade to the new tighter ruleset will have their
> non-compliant blocks orphaned by the hash power majority. This is a strong
> incentive to upgrade and has historically worked well. If a minority
> subset of the network didn’t want to abide by the new restricted rule set,
> a reasonable solution would be for them to change the proof-of-work and
> start a spin-off from the existing Bitcoin ledger (
> https://bitcointalk.org/index.php?topic=563972.0).
>
> In the case of the coming network upgrade to larger blocks, a primary
> concern of both business such as Coinbase and Bitpay, and most miners, is
> the possibility of a blockchain split and the associated confusion, replay
> risk, etc. By applying techniques that are known to be successful for
> soft-forking changes, we can likewise benefit in a way that makes a split
> less likely as we move towards larger blocks. Two proposed techniques to
> reduce the chances of a split are:
>
> 1. That miners begin to orphan the blocks of non-upgraded miners once a
> super-majority of the network hash power has upgraded. This would serve as
> an expensive-to-ignore reminder to upgrade.
>
> 2. That, in the case where a minority branch emerges (unlikely IMO),
> majority miners would continually re-org that minority branch with empty
> blocks to prevent transactions from confirming, thereby eliminating replay
> risk.
>
> Just like after a soft forking change, a minority that does not want to
> abide by the current ruleset enforced by the majority could change the
> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
> suggested by Emin.
>
> Best regards,
> Peter R
>
>
> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
> >> I don't know what "Time is running short I fear" stands for and when 50%
> >> is supposed to be reached
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> > "Time is running short I fear" stands for and when 50% > is supposed
> > to be reached
> >
> > According to current hashrate distribution tracking site coin.dance,
> > very likely within less than four weeks according to current hashrate
> > takeover rate.
> >
> > While a fork is very likely, that I dont really fear because worst
> > case scenario is that bitcoin still survives and the invalid chain
> > becomes an alt. My fear is the centralized mining power being used
> > to attack the valid chain with intentions on killing it. [1]
> >
> > Shouldn't this 50% attack they are threatening be a concern? If it
> > is a concern, what options are on the table. If it is not a concern
> > please enlightent me as to why.
> >
> >
> > [1] Source:
> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_
> rizun_tells_miners_to_force_a_hard_fork_by/
> >
> > Text:
> >
> > The attack quoted from his article:
> > https://medium.com/@peter_r/on-the-emerging-consensus-
> regarding-bitcoins-block-size-limit-insights-from-my-visit-
> with-2348878a16d8
> >
> > [Level 2] Anti-split protection Miners will orphan the
> > blocks of non-compliant miners prior to the first larger block
> > to serve as a reminder to upgrade. Simply due to the possibility
> > of having blocks orphaned, all miners would be motivated to
> > begin signalling for larger blocks once support definitively
> > passes 51%. If some miners hold out (e.g., they may not be
> > paying attention regarding the upgrade), then they will begin
> > to pay attention after losing approximately $15,000 of revenue
> > due to an orphaned block.
> >
> > [Level 3] Anti-split protection In the scenario where Levels
> > 1 and 2 protection fails to entice all non-compliant miners to
> > upgrade, a small-block minority chain may emerge. To address the
> > risk of coins being spent on this chain (replay risk), majority
> > miners will deploy hash power as needed to ensure the minority
> > chain includes only empty blocks after the forking point. This
> > can easily be accomplished if the majority miners maintain a
> > secret chain of empty blocks built off their last empty
> > block publishing only as much of this chain as necessary
> > to orphan any non-empty blocks produced on the minority chain.
> >
> >
> >
> >
> > - --
> > Cannon
> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> > Email: cannon@cannon-ciota.info
> >
> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> > If this matters to you, use PGP.
> > -----BEGIN PGP SIGNATURE-----
> >
> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> > /T93MuZgmvSCry5MlccA
> > =R71g
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > 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
>
[-- Attachment #2: Type: text/html, Size: 9721 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?)
2017-03-25 20:28 ` Peter R
2017-03-26 2:38 ` Alex Morcos
@ 2017-03-26 3:00 ` Eric Voskuil
1 sibling, 0 replies; 22+ messages in thread
From: Eric Voskuil @ 2017-03-26 3:00 UTC (permalink / raw)
To: Peter R, Bitcoin Protocol Discussion
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/25/2017 01:28 PM, Peter R via bitcoin-dev wrote:
> In the case of the coming network upgrade to larger blocks, a
primary concern [...] is the possibility of a blockchain split and the
associated confusion, replay risk, etc.
> [...] a minority that does not want to abide by the [hard fork]
ruleset enforced by the majority could change the proof-of-work and
start a spin-off from the existing Bitcoin ledger [...]
The "spin off" to which you refer is an altcoin. The "network upgrade"
to which you refer is also an altcoin. Both are hard forks from
Bitcoin. I'm having a hard time imagining how a plan to create two new
altcoins from Bitcoin avoids either a split or confusion.
Application of hash power toward the disruption of Bitcoin presumes
participating miners are willing to accept a total loss on these
operations. I can imagine a significant portion of the hash power
deciding to let their competitors donate to "confusion reduction".
Eventually those thrifty miners will put the philanthropists out of
business. Maybe you can get Coinbase and Bitpay to finance the operation
.
This plan seems to be a response to the industry call for replay
protection. Actually writing the code is another option.
> once a super-majority of the network hash power has upgraded.
Despite the fact that nobody (miners included) has any way to measure
what software the economy (or hash power) is running, or what is the
economic weight of that portion of the economy.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY1y7aAAoJEDzYwH8LXOFO9EMH/Aip84JpoYBM8/JIRpjq/wzp
VBU9rwMrVwaKdt8IzdJIhaD8FAiXYmXP6xM3eYk5Jp5g67uBnlrmXqlM/IfHI374
sKvN2nyHNqng9citI6ZeR+B3xJ7oFzycKf+KnvKi5JnPEMuTYwIw+dvXJGvZdjeH
WxW0g63KvfDPvYbYkE1hKnzUHWxGrR/Jrs898Cnwd0Z9OjrVNM3ZEix/IK4QrNRN
e/xLXjuIDHx6nzbddbVOSsuxBDo0GZUufGM4zTrGG+kNy4xFWsfwaXlM6kHmRqGF
73PDFWzbiur4B0CoBA7zd2C2ErypKZOoM35rsvwZq/a23OlxH6Jds7+6jTwN9lQ=
=0Bn2
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 2:38 ` Alex Morcos
@ 2017-03-26 9:13 ` Chris Pacia
2017-03-26 11:27 ` Alex Morcos
2017-03-26 19:05 ` Peter R
1 sibling, 1 reply; 22+ messages in thread
From: Chris Pacia @ 2017-03-26 9:13 UTC (permalink / raw)
To: Alex Morcos, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1611 bytes --]
On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
As a Bitcoin user I find it abhorrent the way you are proposing to
intentionally cripple the chain and rules I want to use instead of just
peacefully splitting.
I just want to point out what appears to be doublespeak going on here.
First, I think it would seem obvious to an observer that a sizable portion
of the community (certainly greater than 5%) view segwit as preventing
"rules I want to use instead of just peacefully splitting" but no
consideration was given to these people when designing segwit as a
softfork. I believe it was Luke who went as far as saying consensus does
not matter when it comes softforks.
Furthermore, when segwit was first introduced it kicked off a round of
softfork/hardfork debate which I participated in. The primary concern that
I and other raised was precisely what is going on now.. that miners could
unilaterally impose an unpopular change to the protocol rules.
At the time I told, rather forcefully, by multiple people that miners have
an "absolute right" to softfork in whatever rules they want. Which, of
course, is absurd on it's face.
But I don't see how people can make such claims on the one hand, and then
complain when this process is used against them.
It amounts to nothing more than "When it's rules I like we get to impose
them on non-consenting users. When it's rules I don't like it's an attack
on the network".
It was completely obvious this entire time that softforks were a very
slippery slope, now we are indeed sliding down that slope.
[-- Attachment #2: Type: text/html, Size: 2421 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 9:13 ` Chris Pacia
@ 2017-03-26 11:27 ` Alex Morcos
0 siblings, 0 replies; 22+ messages in thread
From: Alex Morcos @ 2017-03-26 11:27 UTC (permalink / raw)
To: Chris Pacia; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4202 bytes --]
No I actually agree with a lot of what you said.
I feel there has been a lack of precision and consistency in talking about
these things in the past. This is not intentional, but its just what
happens when a lot of different people are all giving their own arguments.
I tried to be a bit more clear by talking about how soft forks have
historically been done. But certainly the technical definition of a soft
fork is a slippery slope. I completely disagree with the idea that miners
have any right to enforce a soft fork. Even more strongly, I don't think
they have the ability. Censoring a certain class of transactions (such as
those invalid under a soft fork) is something they can unilaterally do, but
it is not the same thing as a soft fork. It is necessarily transient. It
requires nodes to enforce the rules to make it a permanent soft fork.
I do think there are differences between soft forks and hard forks and
consensus requirements and safety for rolling them out. But as mentioned
in my email, I think soft forks should still have a very high bar for
consensus. It's an open question as to whether Core misjudged this for
segwit, although if so, I think it was a close call. The intention is not
to let 95% of miners make the rules (although again, note that it is 95%, a
very high bar, vastly different than 75% of miners). It seems to me that
the vast majority of the community is in favor of segwit. I'm not sure
about your comment that it is obvious to an observer than a sizable portion
of the community is opposed. It is certainly some, and perhaps more than
expected. But this is exactly why the new version bits soft fork roll out
mechanism allows proposals to expire. We did do an extensive job assessing
support for segwit before roll out, and although we knew of a few loud
voices against we judged them to be a very small minority. No business we
contacted was opposed. If it turns out we got it wrong then the proposal
will expire harmlessly. I for one am certainly opposed to forcing segwit
or any other fork of any kind on a significant minority that is opposed.
Despite saying that, I think you will hear some other responses about how
soft forks are opt-in and if you don't like the new features don't use
them. There is some logic behind this idea. But these are all subtleties
which are hard to make strong right and wrong statements about. See some
of the past discussion on this list.
On Sun, Mar 26, 2017 at 4:13 AM, Chris Pacia <ctpacia@gmail.com> wrote:
>
>
> On Mar 25, 2017 10:38 PM, "Alex Morcos via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> I just want to point out what appears to be doublespeak going on here.
>
> First, I think it would seem obvious to an observer that a sizable portion
> of the community (certainly greater than 5%) view segwit as preventing
> "rules I want to use instead of just peacefully splitting" but no
> consideration was given to these people when designing segwit as a
> softfork. I believe it was Luke who went as far as saying consensus does
> not matter when it comes softforks.
>
> Furthermore, when segwit was first introduced it kicked off a round of
> softfork/hardfork debate which I participated in. The primary concern that
> I and other raised was precisely what is going on now.. that miners could
> unilaterally impose an unpopular change to the protocol rules.
>
> At the time I told, rather forcefully, by multiple people that miners have
> an "absolute right" to softfork in whatever rules they want. Which, of
> course, is absurd on it's face.
>
> But I don't see how people can make such claims on the one hand, and then
> complain when this process is used against them.
>
> It amounts to nothing more than "When it's rules I like we get to impose
> them on non-consenting users. When it's rules I don't like it's an attack
> on the network".
>
> It was completely obvious this entire time that softforks were a very
> slippery slope, now we are indeed sliding down that slope.
>
>
>
[-- Attachment #2: Type: text/html, Size: 5473 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 2:38 ` Alex Morcos
2017-03-26 9:13 ` Chris Pacia
@ 2017-03-26 19:05 ` Peter R
2017-03-26 20:20 ` Alphonse Pace
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Peter R @ 2017-03-26 19:05 UTC (permalink / raw)
To: Alex Morcos; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 12797 bytes --]
Hello Alex,
Thank you for the thoughtful reply.
> Surely you are aware that what you are proposing is vastly different from the way soft forks have historically worked.
Yes, it is different. It’s different because the future network upgrade to larger blocks includes a loosening of the consensus ruleset whereas previous upgrades have included a tightening of the rule set. (BTW—this is not my proposal, I am describing what I have recently learned through my work with Bitcoin Unlimited and discussions with miners and businesses).
With a tightening of the rule set, a hash power minority that has not upgraded will not produce a minority branch; instead they will simply have any invalid blocks they produce orphaned, serving as a wake-up call to upgrade.
With a loosening of the consensus rule set, the situation is different: a hash power minority that has not upgraded will produce a minority branch, that will also drag along non-upgraded node operators, leading to potential confusion. The idea behind orphaning the blocks of non-upgraded miners was to serve as a wake-up call to upgrade, to reduce the chances of a minority chain emerging in the first place, similar to what happens automatically with a soft-forking change. If one's worry is a chain split, then this seems like a reasonable way to reduce the chances of that worry materializing. The Level 3 anti-split protection takes this idea one step further to ensure that if a minority branch does emerge, that transactions cannot be confirmed on that branch.
> First of all, the bar for miners being on the new chain is extremely high, 95%.
I’m very confident that most people do NOT want a split, especially the miners. The upgrade to larger blocks will not happen until miners are confident that no minority chain will survive.
> Second of all, soft forks make rule restrictions on classes of transactions that are already non-standard so that any non-upgraded miners are unlikely to be including txs in their blocks which would violate the new rules and should not have their blocks orphaned even after the fork.
I agree that the soft-fork mechanism usually works well. I believe this mechanism (or perhaps a modified version of it) to increase the block size limit will likewise work well. All transactions types that are currently valid will be valid after the upgrade, and no new types of transactions are being created. The “block-size-limit gene" of network nodes is simply evolving to allow the network to continue to grow in the way it has always grown. (If you’re interested, here is my talk at Coinbase where I discuss this: https://www.youtube.com/watch?v=pWnFDocAmfg <https://www.youtube.com/watch?v=pWnFDocAmfg>)
> Finally, soft forks are designed to only be used when there is a very wide community consensus and the intention is not to overrule anyone's choice to remain on the old rules but to ensure the security of nodes that may have neglected to upgrade. Obviously it is impossible to draw a bright line between users who intentionally are not upgrading due to opposition and users that are just being lazy. But in the case of a proposed BU hard fork it is abundantly clear that there is a very significant fraction, in fact likely a majority of users who intentionally want to remain on the old rules.
My read is completely different. I still have never talked with a person in real life who doesn’t want the block size limit to increase. Indeed, I have met people who worry that Bitcoin Unlimited is “trying to take over”—and thus they are worried for other reasons—but this couldn’t be further from the truth. For example, what most people within BU would love to see is a simple patch to Bitcoin Core 0.14 that allows node operators to adjust the size of blocks their nodes will accept, so that these node operators can follow consensus through the upgrade if they choose to.
This is not a fight about “Core vs. BU”; Bitcoin’s future is one of “genetic diversity” with multiple implementations, so that a bug in one doesn’t threaten the network as a whole. To me it seems this is largely a fight about whether node operators should be easily able to adjust the size of blocks their nodes accept. BU makes it easy for node operators to accept larger blocks; Core doesn’t believe users should have this power (outside of recompiling from source, which few users can do).
> As a Bitcoin user I find it abhorrent the way you are proposing to intentionally cripple the chain and rules I want to use instead of just peacefully splitting.
Once again, this is not my proposal. I am writing about what I have come to learn over the past several weeks. When I first heard about these ideas, I was initially against them too. They seemed harsh and merciless. It wasn’t until I got out their and started talking to more people in the community that the rationale started to make sense to me: the biggest concern people had was a chain split!
So I guess the “ethics” here depend on the lens through which one is looking. People who believe that an important outcome of the upgrade to larger blocks is to avoid a blockchain split may be more favourable to these ideas than people who want the upgrade to result in a split (or are OK with a split), as it sounds like you do (is this true that you’d rather split than accept blocks with more than 1,000,000 bytes of transaction information in them? Sorry if I misunderstood).
But if one's intention is to split and not follow the majority hash power when blocks become larger, then why not change the proof-of-work? This would certainly result in a peaceful splitting, as you said you desire.
Best regards,
Peter R
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> One of the purported benefits of a soft-forking change (a tightening of the consensus rule set) is the reduced risk of a blockchain split compared to a loosening of the consensus rule set. The way this works is that miners who fail to upgrade to the new tighter ruleset will have their non-compliant blocks orphaned by the hash power majority. This is a strong incentive to upgrade and has historically worked well. If a minority subset of the network didn’t want to abide by the new restricted rule set, a reasonable solution would be for them to change the proof-of-work and start a spin-off from the existing Bitcoin ledger (https://bitcointalk.org/index.php?topic=563972.0 <https://bitcointalk.org/index.php?topic=563972.0>).
>
> In the case of the coming network upgrade to larger blocks, a primary concern of both business such as Coinbase and Bitpay, and most miners, is the possibility of a blockchain split and the associated confusion, replay risk, etc. By applying techniques that are known to be successful for soft-forking changes, we can likewise benefit in a way that makes a split less likely as we move towards larger blocks. Two proposed techniques to reduce the chances of a split are:
>
> 1. That miners begin to orphan the blocks of non-upgraded miners once a super-majority of the network hash power has upgraded. This would serve as an expensive-to-ignore reminder to upgrade.
>
> 2. That, in the case where a minority branch emerges (unlikely IMO), majority miners would continually re-org that minority branch with empty blocks to prevent transactions from confirming, thereby eliminating replay risk.
>
> Just like after a soft forking change, a minority that does not want to abide by the current ruleset enforced by the majority could change the proof-of-work and start a spin-off from the existing Bitcoin ledger, as suggested by Emin.
>
> Best regards,
> Peter R
>
>
> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
> >> I don't know what "Time is running short I fear" stands for and when 50%
> >> is supposed to be reached
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> > "Time is running short I fear" stands for and when 50% > is supposed
> > to be reached
> >
> > According to current hashrate distribution tracking site coin.dance,
> > very likely within less than four weeks according to current hashrate
> > takeover rate.
> >
> > While a fork is very likely, that I dont really fear because worst
> > case scenario is that bitcoin still survives and the invalid chain
> > becomes an alt. My fear is the centralized mining power being used
> > to attack the valid chain with intentions on killing it. [1]
> >
> > Shouldn't this 50% attack they are threatening be a concern? If it
> > is a concern, what options are on the table. If it is not a concern
> > please enlightent me as to why.
> >
> >
> > [1] Source:
> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/ <https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/>
> >
> > Text:
> >
> > The attack quoted from his article:
> > https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8 <https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8>
> >
> > [Level 2] Anti-split protection Miners will orphan the
> > blocks of non-compliant miners prior to the first larger block
> > to serve as a reminder to upgrade. Simply due to the possibility
> > of having blocks orphaned, all miners would be motivated to
> > begin signalling for larger blocks once support definitively
> > passes 51%. If some miners hold out (e.g., they may not be
> > paying attention regarding the upgrade), then they will begin
> > to pay attention after losing approximately $15,000 of revenue
> > due to an orphaned block.
> >
> > [Level 3] Anti-split protection In the scenario where Levels
> > 1 and 2 protection fails to entice all non-compliant miners to
> > upgrade, a small-block minority chain may emerge. To address the
> > risk of coins being spent on this chain (replay risk), majority
> > miners will deploy hash power as needed to ensure the minority
> > chain includes only empty blocks after the forking point. This
> > can easily be accomplished if the majority miners maintain a
> > secret chain of empty blocks built off their last empty
> > block publishing only as much of this chain as necessary
> > to orphan any non-empty blocks produced on the minority chain.
> >
> >
> >
> >
> > - --
> > Cannon
> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> > Email: cannon@cannon-ciota.info <mailto:cannon@cannon-ciota.info>
> >
> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> > If this matters to you, use PGP.
> > -----BEGIN PGP SIGNATURE-----
> >
> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> > /T93MuZgmvSCry5MlccA
> > =R71g
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
[-- Attachment #2: Type: text/html, Size: 17248 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 19:05 ` Peter R
@ 2017-03-26 20:20 ` Alphonse Pace
2017-03-26 20:22 ` Bryan Bishop
2017-03-26 22:15 ` Eric Voskuil
2 siblings, 0 replies; 22+ messages in thread
From: Alphonse Pace @ 2017-03-26 20:20 UTC (permalink / raw)
To: Peter R, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 13251 bytes --]
As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem. Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would. If you wish to fork off, please do so responsibly.
-Alphonse
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different. It’s different because the future network upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set. (BTW—this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potential
> confusion. The idea behind orphaning the blocks of non-upgraded miners was
> to serve as a wake-up call to upgrade, to reduce the chances of a minority
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change. If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing. The Level 3 anti-split protection takes this idea one step
> further to ensure that if a minority branch does emerge, that transactions
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high,
> 95%.
>
>
> I’m very confident that most people do NOT want a split, especially the
> miners. The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miners
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well. I believe this
> mechanism (or perhaps a modified version of it) to increase the block size
> limit will likewise work well. All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions are
> being created. The “block-size-limit gene" of network nodes is simply
> evolving to allow the network to continue to grow in the way it has always
> grown. (If you’re interested, here is my talk at Coinbase where I discuss
> this: https://www.youtube.com/watch?v=pWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wide
> community consensus and the intention is not to overrule anyone's choice to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade. Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy. But in the case of a proposed BU hard fork
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different. I still have never talked with a person
> in real life who doesn’t want the block size limit to increase. Indeed, I
> have met people who worry that Bitcoin Unlimited is “trying to take
> over”—and thus they are worried for other reasons—but this couldn’t be
> further from the truth. For example, what most people within BU would love
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one of
> “genetic diversity” with multiple implementations, so that a bug in one
> doesn’t threaten the network as a whole. To me it seems this is largely a
> fight about whether node operators should be easily able to adjust the size
> of blocks their nodes accept. BU makes it easy for node operators to
> accept larger blocks; Core doesn’t believe users should have this power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> Once again, this is not my proposal. I am writing about what I have come
> to learn over the past several weeks. When I first heard about these
> ideas, I was initially against them too. They seemed harsh and merciless.
> It wasn’t until I got out their and started talking to more people in the
> community that the rationale started to make sense to me: the biggest
> concern people had was a chain split!
>
> So I guess the “ethics” here depend on the lens through which one is
> looking. People who believe that an important outcome of the upgrade to
> larger blocks is to avoid a blockchain split may be more favourable to
> these ideas than people who want the upgrade to result in a split (or are
> OK with a split), as it sounds like you do (is this true that you’d rather
> split than accept blocks with more than 1,000,000 bytes of transaction
> information in them? Sorry if I misunderstood).
>
> But if one's intention is to split and not follow the majority hash power
> when blocks become larger, then why not change the proof-of-work? This
> would certainly result in a peaceful splitting, as you said you desire.
>
> Best regards,
> Peter R
>
>
>
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> One of the purported benefits of a soft-forking change (a tightening of
>> the consensus rule set) is the reduced risk of a blockchain split compared
>> to a loosening of the consensus rule set. The way this works is that
>> miners who fail to upgrade to the new tighter ruleset will have their
>> non-compliant blocks orphaned by the hash power majority. This is a strong
>> incentive to upgrade and has historically worked well. If a minority
>> subset of the network didn’t want to abide by the new restricted rule set,
>> a reasonable solution would be for them to change the proof-of-work and
>> start a spin-off from the existing Bitcoin ledger (
>> https://bitcointalk.org/index.php?topic=563972.0).
>>
>> In the case of the coming network upgrade to larger blocks, a primary
>> concern of both business such as Coinbase and Bitpay, and most miners, is
>> the possibility of a blockchain split and the associated confusion, replay
>> risk, etc. By applying techniques that are known to be successful for
>> soft-forking changes, we can likewise benefit in a way that makes a split
>> less likely as we move towards larger blocks. Two proposed techniques to
>> reduce the chances of a split are:
>>
>> 1. That miners begin to orphan the blocks of non-upgraded miners once a
>> super-majority of the network hash power has upgraded. This would serve as
>> an expensive-to-ignore reminder to upgrade.
>>
>> 2. That, in the case where a minority branch emerges (unlikely IMO),
>> majority miners would continually re-org that minority branch with empty
>> blocks to prevent transactions from confirming, thereby eliminating replay
>> risk.
>>
>> Just like after a soft forking change, a minority that does not want to
>> abide by the current ruleset enforced by the majority could change the
>> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
>> suggested by Emin.
>>
>> Best regards,
>> Peter R
>>
>>
>> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> >> I don't know what "Time is running short I fear" stands for and when
>> 50%
>> >> is supposed to be reached
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
>> > "Time is running short I fear" stands for and when 50% > is supposed
>> > to be reached
>> >
>> > According to current hashrate distribution tracking site coin.dance,
>> > very likely within less than four weeks according to current hashrate
>> > takeover rate.
>> >
>> > While a fork is very likely, that I dont really fear because worst
>> > case scenario is that bitcoin still survives and the invalid chain
>> > becomes an alt. My fear is the centralized mining power being used
>> > to attack the valid chain with intentions on killing it. [1]
>> >
>> > Shouldn't this 50% attack they are threatening be a concern? If it
>> > is a concern, what options are on the table. If it is not a concern
>> > please enlightent me as to why.
>> >
>> >
>> > [1] Source:
>> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun
>> _tells_miners_to_force_a_hard_fork_by/
>> >
>> > Text:
>> >
>> > The attack quoted from his article:
>> > https://medium.com/@peter_r/on-the-emerging-consensus-regard
>> ing-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>> >
>> > [Level 2] Anti-split protection Miners will orphan the
>> > blocks of non-compliant miners prior to the first larger block
>> > to serve as a reminder to upgrade. Simply due to the possibility
>> > of having blocks orphaned, all miners would be motivated to
>> > begin signalling for larger blocks once support definitively
>> > passes 51%. If some miners hold out (e.g., they may not be
>> > paying attention regarding the upgrade), then they will begin
>> > to pay attention after losing approximately $15,000 of revenue
>> > due to an orphaned block.
>> >
>> > [Level 3] Anti-split protection In the scenario where Levels
>> > 1 and 2 protection fails to entice all non-compliant miners to
>> > upgrade, a small-block minority chain may emerge. To address the
>> > risk of coins being spent on this chain (replay risk), majority
>> > miners will deploy hash power as needed to ensure the minority
>> > chain includes only empty blocks after the forking point. This
>> > can easily be accomplished if the majority miners maintain a
>> > secret chain of empty blocks built off their last empty
>> > block publishing only as much of this chain as necessary
>> > to orphan any non-empty blocks produced on the minority chain.
>> >
>> >
>> >
>> >
>> > - --
>> > Cannon
>> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> > Email: cannon@cannon-ciota.info
>> >
>> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> > If this matters to you, use PGP.
>> > -----BEGIN PGP SIGNATURE-----
>> >
>> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
>> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
>> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
>> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
>> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
>> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
>> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
>> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
>> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
>> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
>> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
>> > /T93MuZgmvSCry5MlccA
>> > =R71g
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > 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
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 16463 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 19:05 ` Peter R
2017-03-26 20:20 ` Alphonse Pace
@ 2017-03-26 20:22 ` Bryan Bishop
2017-03-26 20:37 ` Trevin Hofmann
` (2 more replies)
2017-03-26 22:15 ` Eric Voskuil
2 siblings, 3 replies; 22+ messages in thread
From: Bryan Bishop @ 2017-03-26 20:22 UTC (permalink / raw)
To: Peter R, Bitcoin Protocol Discussion, Bryan Bishop
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 1138 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 20:22 ` Bryan Bishop
@ 2017-03-26 20:37 ` Trevin Hofmann
2017-03-26 20:44 ` Bryan Bishop
2017-03-26 21:12 ` Eric Voskuil
2017-03-26 21:42 ` Tom Harding
2 siblings, 1 reply; 22+ messages in thread
From: Trevin Hofmann @ 2017-03-26 20:37 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1655 bytes --]
>> With a tightening of the rule set, a hash power minority that has not
upgraded will not produce a minority branch; instead they will simply have
any invalid blocks they produce orphaned, serving as a wake-up call t>o
upgrade.
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
will not be orphaned unless they are intentionally segwit-invalid (which
they currently are not). If you have told miners otherwise, let me know.
He stated that "any invalid blocks they produce" will be orphaned. This is
not false. If non-upgraded miners do not produce blocks that are invalid
per the new rules, their blocks will not be orphaned. This is consistent
with Peter's comment.
-Trevin
On Sun, Mar 26, 2017 at 3:22 PM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> With a tightening of the rule set, a hash power minority that has not
>> upgraded will not produce a minority branch; instead they will simply have
>> any invalid blocks they produce orphaned, serving as a wake-up call to
>> upgrade.
>>
>
> False. With bip9-based soft-fork-based activation of segwit, miner blocks
> will not be orphaned unless they are intentionally segwit-invalid (which
> they currently are not). If you have told miners otherwise, let me know.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3040 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 20:37 ` Trevin Hofmann
@ 2017-03-26 20:44 ` Bryan Bishop
0 siblings, 0 replies; 22+ messages in thread
From: Bryan Bishop @ 2017-03-26 20:44 UTC (permalink / raw)
To: Trevin Hofmann, Bryan Bishop; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann <trevinhofmann@gmail.com>
wrote:
> He stated that "any invalid blocks they produce" will be orphaned. This is
> not false. If non-upgraded miners do not produce blocks that are invalid
> per the new rules, their blocks will not be orphaned. This is consistent
> with Peter's comment.
It's the other part of the statement- the "wakeup call to upgrade" from
producing invalid blocks? They aren't producing invalid blocks.
Additionally, if they want to be even more sure about this, they can run
the so-called "border nodes". No wakeup calls needed.... the point of a
soft-fork is to reduce incompatibility.
- Bryan
http://heybryan.org/
1 512 203 0507
[-- Attachment #2: Type: text/html, Size: 1171 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 20:22 ` Bryan Bishop
2017-03-26 20:37 ` Trevin Hofmann
@ 2017-03-26 21:12 ` Eric Voskuil
2017-03-26 21:42 ` Tom Harding
2 siblings, 0 replies; 22+ messages in thread
From: Eric Voskuil @ 2017-03-26 21:12 UTC (permalink / raw)
To: Bryan Bishop, Bitcoin Protocol Discussion, Peter R
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/26/2017 01:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
>
> False. With bip9-based soft-fork-based activation of segwit, miner
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told
> miners otherwise, let me know.
Given the protocol requirements of the segwit proposal this is not the
case. A miner running pre-segwit code will produce blocks that no
segwit node will ever receive. It matters not whether these blocks
contain transactions that are invalidated by the soft fork. Despite
being valid to other pre-segwit nodes they will never be built upon by
the majority hash power once segwit activates.
At the same time, Peter's comment above is also incorrect. A "minority
branch" *is* a set of blocks that have been orphaned (the term orphan
being a misnomer, since these blocks of course have an ancestry all
the way to the genesis block). That's precisely what is implied by the
word "minority". So his description contradicts itself.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY2C6pAAoJEDzYwH8LXOFOf4gH/2e/euZ9bQxPKZyC7DN8us6T
R1R9f+JFFsU3Vo8HkcU028Ib4aF0IAELvAWrhpZfH6ixZV2c3CJoi53rMbPmJ/+H
Rlj0Qjc58mYpqosxyNoi0qPFZ2e3yCv+R5v9PQEeOdcGwXIr77Tij8lI1yu4uqHU
bqJ3BXJLFpvL5iXOLhbakeu2qVIHqJnb1/hQMNh6eNM794n+UT2T8You52xUkuTm
zJ+5CTQUiMNFE/HBWsbk8Vf3BTrM0sqMRTJzdr4VT1l+uOZn58BJJPFzLr2WeZww
klAB/wK5oExMNlKQVy6Rw9+uFx88qRTl5s7LwFASOxEZYJIjd36bBaoTdqfaB5U=
=pvlp
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 20:22 ` Bryan Bishop
2017-03-26 20:37 ` Trevin Hofmann
2017-03-26 21:12 ` Eric Voskuil
@ 2017-03-26 21:42 ` Tom Harding
2 siblings, 0 replies; 22+ messages in thread
From: Tom Harding @ 2017-03-26 21:42 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On 3/26/2017 1:22 PM, Bryan Bishop via bitcoin-dev wrote:
> On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
>
>
> False. With bip9-based soft-fork-based activation of segwit, miner
> blocks will not be orphaned unless they are intentionally
> segwit-invalid (which they currently are not). If you have told miners
> otherwise, let me know.
>
A reasonable miner automatically checks every transaction seen, to see
if it might be valid with his own outputs substituted.
[-- Attachment #2: Type: text/html, Size: 1971 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 19:05 ` Peter R
2017-03-26 20:20 ` Alphonse Pace
2017-03-26 20:22 ` Bryan Bishop
@ 2017-03-26 22:15 ` Eric Voskuil
2017-03-27 10:25 ` Aymeric Vitte
2 siblings, 1 reply; 22+ messages in thread
From: Eric Voskuil @ 2017-03-26 22:15 UTC (permalink / raw)
To: Peter R, Bitcoin Protocol Discussion, Alex Morcos
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:
Peter,
> Yes, it is different. It’s different because the future network
> upgrade to larger blocks includes a loosening of the consensus
> ruleset whereas previous upgrades have included a tightening of the
> rule set. (BTW—this is not my proposal, I am describing what I
> have recently learned through my work with Bitcoin Unlimited and
> discussions with miners and businesses).
The repeated use of the term "network upgrade" in place of the
accepted technical term (hard fork) is misleading. This and the
presupposition that the hard fork is coming, and the claims that it's
not your proposal, make me feel like I'm shopping for a used car...
It's not used it's pre-owned, everyone's getting the warranty, let me
see what my manager has to say about the price - it's not my decision.
This is a development list. Avoidance of standardized terminology and
use of the presumptive close diminishes your message.
> With a tightening of the rule set, a hash power minority that has
> not upgraded will not produce a minority branch; instead they will
> simply have any invalid blocks they produce orphaned, serving as a
> wake-up call to upgrade.
"tightening of the rule set" == soft fork
This implies that the minority hash power is producing blocks that are
valid according to rules in existence prior to the soft fork. You are
referring to these as invalid, but because this has already confused
one commentator, let's be clear. The blocks you are referring to are
valid blocks being orphaned because the majority hash power is
rejecting them because of soft fork activation. This of course
produces a minority chain, so this statement is incorrect.
> With a loosening of the consensus rule set, the situation is
> different: a hash power minority that has not upgraded will produce
> a minority branch, that will also drag along non-upgraded node
> operators, leading to potential confusion.
"loosening of the consensus rule set" == hard fork
This is also incorrect. In the case of a hard fork old nodes reject
the new blocks that are invalid according to old rules and continue to
accept other old blocks. This produces a second distinct chain. It is
neither a majority nor a minority chain with respect to the original.
It is simply a new coin that happens to share history with the old
coin. This doesn't imply confusion, since both chains continue to
operate under the rules of their nodes. The only confusion arises from
people wanting to transaction across *both* chains. It is only in this
context that replay becomes an issue.
> The idea behind orphaning the blocks of non-upgraded miners was to
> serve as a wake-up call to upgrade, to reduce the chances of a
> minority chain emerging in the first place, similar to what happens
> automatically with a soft-forking change. If one's worry is a
> chain split, then this seems like a reasonable way to reduce the
> chances of that worry materializing. The Level 3 anti-split
> protection takes this idea one step further to ensure that if a
> minority branch does emerge, that transactions cannot be confirmed
> on that branch.
Stopping people from transacting on the old chain due to an ongoing
51% attack (again, using proper terminology) is one way to make it
hard for people to transact on both chains. But if you don't care that
people are able to transact on both chains, there's no reason to spend
the money on the attack.
So let me point to the elephant in the room. The proposed 51% attack
is more obviously an attempt to transfer economic activity from BTC to
BTU, not a benevolent measure to prevent confusion. It can clearly be
viewed as elimination of competition through an electronic attack on
BTC operations. Given that they are all regulated entities, I'm not
sure how the envisioned large miner collaborators (or others who might
fund it) will feel about participation in the scheme.
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one
> of “genetic diversity” with multiple implementations, so that a bug
> in one doesn’t threaten the network as a whole
You are right that this is not about Core and BU. These are
implementations, not protocols. However, please do not presume that
other implementations are enlisted in your scheme, or that this is
about making the network more bug-resistant.
> To me it seems this is largely a fight about whether node operators
> should be easily able to adjust the size of blocks their nodes
> accept. BU makes it easy for node operators to accept larger
> blocks; Core doesn’t believe users should have this power (outside
> of recompiling from source, which few users can do).
I feel like making the block size a configuration option in Libbitcoin
just to emphasize the gross error of this idea. It has never been
about the inability of users to compile the code. It's about the
purposeful difficulty in changing the rules when everyone has a say.
> Once again, this is not my proposal. I am writing about what I
> have come to learn over the past several weeks. When I first heard
> about these ideas, I was initially against them too. They seemed
> harsh and merciless. It wasn’t until I got out their and started
> talking...
The idea was so powerful you were converted (another sales tactic).
Who's proposal is this? Can they not speak for themselves?
> So I guess the “ethics” here depend on the lens through which one
> is looking...
These are not ethical questions. These are development questions,
built on economic concepts, backed by individual financial decisions.
There is no equivalence of ideas based on one's arbitrary perspective.
> But if one's intention is to split and not follow the majority
> hash power when blocks become larger,
The "split" is always by the one that hard forks. The splitter is the
one who changes what exists and therefore creates something new.
Please fix your terminology.
> then why not change the proof-of-work? This would certainly result
> in a peaceful splitting, as you said you desire.
A hard fork, including changing the PoW algorithm, requires the
purposely improbable coordination of the economy in the creation of a
new coin and the abandonment of the old. This should be apparent from
the ongoing block size hard fork attempts.
e
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJY2D2SAAoJEDzYwH8LXOFO3r0H/R0PTi2x15Zj1oceOqcNpP4k
/TrTohFl/BRE4PaOqJ9n9DbJ6W8rnAjRnguOIgOB1CSIRCuy73AQ4aqRSTCBlHbe
VVrlKKFS8zh50Cjg8tlnomWeKe1YDO31R2Avises+Dr3kyqQ9+QYtOoqxvuvYrXo
B03fjPIL0eTQypA4KP/W7CxrlHN7oyN+PtehpI51JOGMxx6Xc0RDelGz1NTlQQ1f
90Axeey51tgAzJ8wsC+Vf22hZdU06VDdtG8PSHVcrELoicDnEjR4T+1XqA1hcAY2
hWBX5qpQYJqJv1ypfTH0ouh6QtLhJZGCWzKZnpH+T7d3FUG+AXn0UjTP3Nkh7NY=
=Cc8r
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-26 22:15 ` Eric Voskuil
@ 2017-03-27 10:25 ` Aymeric Vitte
0 siblings, 0 replies; 22+ messages in thread
From: Aymeric Vitte @ 2017-03-27 10:25 UTC (permalink / raw)
To: Eric Voskuil, Bitcoin Protocol Discussion
Le 27/03/2017 à 00:15, Eric Voskuil via bitcoin-dev a écrit :
> On 03/26/2017 12:05 PM, Peter R via bitcoin-dev wrote:
>
>
>
> The repeated use of the term "network upgrade" in place of the
> accepted technical term (hard fork) is misleading. This and the
> presupposition that the hard fork is coming, and the claims that it's
> not your proposal, make me feel like I'm shopping for a used car...
> It's not used it's pre-owned, everyone's getting the warranty, let me
> see what my manager has to say about the price - it's not my decision.
>
> This is a development list. Avoidance of standardized terminology and
> use of the presumptive close diminishes your message.
>
>
>
> The idea was so powerful you were converted (another sales tactic).
> Who's proposal is this? Can they not speak for themselves?
>
>
What is the rationale to come on this list (on behalf of we don't know
whom) and explain all the details of the "network upgrade" (ie the
attack) if this is not to try to get some information to confirm the
theory and/or improve it, or some information about how it will be
defeated? This just shows that they are not sure about the whole thing,
they should stop this now, launch their approximative BU if they like
and leave BTC alone
--
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
2017-03-24 16:27 ` Emin Gün Sirer
@ 2017-04-14 2:22 ` CANNON
0 siblings, 0 replies; 22+ messages in thread
From: CANNON @ 2017-04-14 2:22 UTC (permalink / raw)
To: Emin Gün Sirer, Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 03/24/2017 04:27 PM, Emin Gün Sirer wrote:
> Because there's no consensus on the contents of the mempool, this approach
> is unsafe and will lead to forks. It also opens a new attack vector where
> people can time the flood of new transactions with the discovery of a block
> by a competitor, to orphan the block and to fork the chain.
>
I know this is a delayed reply.
Without intending to revive an older thread, my intentions are to clarify
what I have meant in my original post just in case anyone misinterprets
where I said
"For example would be something like this:
If block = (empty OR <%75 of mempool) THEN discard
This threshold just an example."
I should have clarified that with this idea blocks would not be rejected if
does not match what that nodes have in their mempool, because as you have said,
there is no consensus on the contents of mempool and the mempool will vary from
node to node.
Instead what I have meant is that with this idea, nodes would only reject blocks if
they are empty or less than a determined percentage when compared to what is in mempool.
While this specific defense proposal I posted may or may not be a good idea, was only
throwing this idea out there to create discussion on possible defenses against an empty
or near empty block attack.
- --
Cannon
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
Email: cannon@cannon-ciota.info
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
If this matters to you, use PGP.
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY8DIZAAoJEAYDai9lH2mwZKYP/jNJjyTeE09+IlsGolPV3Vp+
suJmUK26y8IbEzGxa8eVoX3w7407VNzqeT0jF8vK7oy97EPgszoiutbzYanKYH27
Rpck+FdW/Q5o6jqw59swX+KEvVao52ETPX3kV8ae5uA2txOBnn6C0qZbM5OxPVLN
IHr7E0+bn9BQVuTzhep1wNWi4cDzyeIjYfRGArBTkuSBKxFtbPmTMLa67qsBGKVu
JcGYm6rdDO0iVAR9od/Is9b+3gTW49x/3jBEdg7iCHc8KuGOilZaHfyU6xjt3fPo
L2lxXxUuobFD68/f4ervFVMpAPpmPaS/MEkHMIhJex3szdlSe/WZsQm+2/j799Rg
Ba62pMOYvSR43WwlwX8eySUlVsPtJNtObKnRvDBOmOICgsZ3T9tHKjI+9IPVi9Ib
s7yBBA1LFw4+c8wirzu1aaeDroJ3icqfU+tRe+nadQN1PMepk6sBUMu13bm8B3E3
R8oo+jFZRRvJmx7HDDlJX9GHri8hktCNm/gtt0ksWwEgAQHixukmKoDVssAmsiZ4
BbiWIA3ULciSKM782zDH7/GvDBbOurtV8TeubnV7DDARIA86COwuGjjk30Ltf3ia
5gnFIicLkmdRMh4AU0jvvEpxrHWFFJmreoR+jnAXHMBGoA6ExVaqR2VQzcpb5SIb
sqe/5499BqvJqS4ZFn7f
=q+nx
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-04-14 2:22 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-24 16:03 [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? CANNON
2017-03-24 16:27 ` Emin Gün Sirer
2017-04-14 2:22 ` CANNON
2017-03-24 17:29 ` Nick ODell
2017-03-24 17:37 ` Hampus Sjöberg
2017-03-24 19:00 ` Aymeric Vitte
2017-03-25 16:12 ` CANNON
2017-03-25 20:28 ` Peter R
2017-03-26 2:38 ` Alex Morcos
2017-03-26 9:13 ` Chris Pacia
2017-03-26 11:27 ` Alex Morcos
2017-03-26 19:05 ` Peter R
2017-03-26 20:20 ` Alphonse Pace
2017-03-26 20:22 ` Bryan Bishop
2017-03-26 20:37 ` Trevin Hofmann
2017-03-26 20:44 ` Bryan Bishop
2017-03-26 21:12 ` Eric Voskuil
2017-03-26 21:42 ` Tom Harding
2017-03-26 22:15 ` Eric Voskuil
2017-03-27 10:25 ` Aymeric Vitte
2017-03-26 3:00 ` [bitcoin-dev] Two altcoins and a 51% attack (was: Defending against empty or near empty blocks from malicious miner takeover?) Eric Voskuil
2017-03-24 19:00 ` [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? Aymeric Vitte
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox