* [bitcoin-dev] Introducing a POW through a soft-fork
@ 2017-11-01 5:48 Devrandom
2017-11-02 23:55 ` Tao Effect
2017-11-06 19:50 ` Peter Todd
0 siblings, 2 replies; 10+ messages in thread
From: Devrandom @ 2017-11-01 5:48 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 4398 bytes --]
Hi all,
Feedback is welcome on the draft below. In particular, I want to see if
there is interest in further development of the idea and also interested in
any attack vectors or undesirable dynamics.
(Formatted version available here:
https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
# Soft-fork Introduction of a New POW
## Motivation:
- Mitigate mining centralization pressures by introducing a POW that does
not have economies of scale
- Introduce an intermediary confirmation point, reducing the impact of
mining power fluctuations
Note however that choice of a suitable POW will require deep analysis.
Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are
not, unexpected/covert optimization.
In particular, unexpected/covert optimizations, such as ASCIBOOST, present
a potential centralizing and destabilizing force.
## Design
### Aux POW intermediate block
Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
alternates between the two POWs.
Each aux-POW block points to the previous normal block and contains
transactions just like a normal block.
Each normal block points to the previous aux-POW block and must contain all
transactions from the aux-POW block.
Block space is not increased.
The new intermediate block and the pointers are introduced via a soft-fork
restriction.
### Reward for aux POW miners
The reward for the aux POW smoothly increases from zero to a target value
(e.g. 1/2 of the total reward) over time.
The reward is transferred via a soft-fork restriction requiring a coinbase
output to an address published in the
aux-POW block.
### Aux POW difficulty adjustment
Difficulty adjustments remain independent for the two POWs.
The difficulty of the aux POW is adjusted based on the average time between
normal block found
to aux block found.
Further details are dependent on the specific POW.
### Heaviest chain rule change
This is a semi-hard change, because non-upgraded nodes can get on the wrong
chain in case of attack. However,
it might be possible to construct an alert system that notifies
non-upgraded nodes of an upcoming rule change.
All blocks are still valid, so this is not a hardforking change.
The heaviest chain definition changes from sum of `difficulty` to sum of:
mainDifficulty ^ x * auxDifficulty ^ y
where we start at:
x = 1; y = 0
and end at values of x and y that are related to the target relative
rewards. For example, if the target rewards
are equally distributed, we will want ot end up at:
x = 1/2; y = 1/2
so that both POWs have equal weight. If the aux POW is to become dominant,
x should end small relative to y.
## Questions and Answers
- What should be the parameters if we want the aux POW to have equal
weight? A: 1/2 of the reward should be transferred
to aux miners and x = 1/2, y = 1/2.
- What should be the parameters if we want to deprecate the main POW? A:
most of the reward should be transferred to
aux miners and x = 0, y = 1. The main difficulty will tend to zero, and
aux miners will just trivially generate the
main block immediately after finding an aux block, with identical content.
- Wasted bandwidth to transfer transactions twice? A: this can be
optimized by skipping transactions already
transferred.
- Why would miners agree to soft-fork away some of their reward? A: they
would agree if they believe that
the coins will increase in value due to improved security properties.
## Open Questions
- After a block of one type is found, we can naively assume that POW will
become idle while a block of the other type is being mined. In practice,
the spare capacity can be used to find alternative ("attacking") blocks or
mine other coins. Is that a problem?
- Is selfish mining amplified by this scheme for miners that have both
types of hardware?
## POW candidates
- SHA256 (i.e. use same POW, but introduce an intermediate block for faster
confirmation)
- Proof of Space and Time (Bram Cohen)
- Equihash
- Ethash
## Next Steps
- evaluate POW candidates
- evaluate difficulty adjustment rules
- simulate miner behavior to identify if there are incentives for
detrimental behavior patterns (e.g. block withholding / selfish mining)
- Protocol details
## Credits
Bram Cohen came up with a similar idea back in March:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html
[-- Attachment #2: Type: text/html, Size: 6144 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-01 5:48 [bitcoin-dev] Introducing a POW through a soft-fork Devrandom
@ 2017-11-02 23:55 ` Tao Effect
2017-11-03 1:02 ` Devrandom
2017-11-06 19:50 ` Peter Todd
1 sibling, 1 reply; 10+ messages in thread
From: Tao Effect @ 2017-11-02 23:55 UTC (permalink / raw)
To: Devrandom, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 5520 bytes --]
Just going to throw in my support for a POW change, not any particular implementation, but the idea.
Bitcoin is technically owned by China now. That's not acceptable.
- Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> Hi all,
>
> Feedback is welcome on the draft below. In particular, I want to see if there is interest in further development of the idea and also interested in any attack vectors or undesirable dynamics.
>
> (Formatted version available here: https://github.com/devrandom/btc-papers/blob/master/aux-pow.md <https://github.com/devrandom/btc-papers/blob/master/aux-pow.md> )
>
> # Soft-fork Introduction of a New POW
>
> ## Motivation:
>
> - Mitigate mining centralization pressures by introducing a POW that does not have economies of scale
> - Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations
>
> Note however that choice of a suitable POW will require deep analysis. Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are not, unexpected/covert optimization.
>
> In particular, unexpected/covert optimizations, such as ASCIBOOST, present a potential centralizing and destabilizing force.
>
> ## Design
>
> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain all transactions from the aux-POW block.
> Block space is not increased.
>
> The new intermediate block and the pointers are introduced via a soft-fork restriction.
>
> ### Reward for aux POW miners
>
> The reward for the aux POW smoothly increases from zero to a target value (e.g. 1/2 of the total reward) over time.
> The reward is transferred via a soft-fork restriction requiring a coinbase output to an address published in the
> aux-POW block.
>
> ### Aux POW difficulty adjustment
>
> Difficulty adjustments remain independent for the two POWs.
>
> The difficulty of the aux POW is adjusted based on the average time between normal block found
> to aux block found.
>
> Further details are dependent on the specific POW.
>
> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the wrong chain in case of attack. However,
> it might be possible to construct an alert system that notifies non-upgraded nodes of an upcoming rule change.
> All blocks are still valid, so this is not a hardforking change.
>
> The heaviest chain definition changes from sum of `difficulty` to sum of:
>
> mainDifficulty ^ x * auxDifficulty ^ y
>
> where we start at:
>
> x = 1; y = 0
>
> and end at values of x and y that are related to the target relative rewards. For example, if the target rewards
> are equally distributed, we will want ot end up at:
>
> x = 1/2; y = 1/2
>
> so that both POWs have equal weight. If the aux POW is to become dominant, x should end small relative to y.
>
>
> ## Questions and Answers
>
> - What should be the parameters if we want the aux POW to have equal weight? A: 1/2 of the reward should be transferred
> to aux miners and x = 1/2, y = 1/2.
>
> - What should be the parameters if we want to deprecate the main POW? A: most of the reward should be transferred to
> aux miners and x = 0, y = 1. The main difficulty will tend to zero, and aux miners will just trivially generate the
> main block immediately after finding an aux block, with identical content.
>
> - Wasted bandwidth to transfer transactions twice? A: this can be optimized by skipping transactions already
> transferred.
>
> - Why would miners agree to soft-fork away some of their reward? A: they would agree if they believe that
> the coins will increase in value due to improved security properties.
>
> ## Open Questions
>
> - After a block of one type is found, we can naively assume that POW will become idle while a block of the other type is being mined. In practice, the spare capacity can be used to find alternative ("attacking") blocks or mine other coins. Is that a problem?
> - Is selfish mining amplified by this scheme for miners that have both types of hardware?
>
> ## POW candidates
>
> - SHA256 (i.e. use same POW, but introduce an intermediate block for faster confirmation)
> - Proof of Space and Time (Bram Cohen)
> - Equihash
> - Ethash
>
> ## Next Steps
>
> - evaluate POW candidates
> - evaluate difficulty adjustment rules
> - simulate miner behavior to identify if there are incentives for detrimental behavior patterns (e.g. block withholding / selfish mining)
> - Protocol details
>
> ## Credits
>
> Bram Cohen came up with a similar idea back in March:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html>_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #1.2: Type: text/html, Size: 11044 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-02 23:55 ` Tao Effect
@ 2017-11-03 1:02 ` Devrandom
0 siblings, 0 replies; 10+ messages in thread
From: Devrandom @ 2017-11-03 1:02 UTC (permalink / raw)
To: Tao Effect; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5586 bytes --]
I am also concerned. However, this proposal allows two POWs to coexist and
allows for gradual transitions. This is hopefully a less disruptive
approach since it allows cooperative miners to migrate over time. And of
course, as a soft-fork it keeps backwards compatibility with existing
software.
On Thu, Nov 2, 2017 at 4:55 PM Tao Effect <contact@taoeffect•com> wrote:
> Just going to throw in my support for a POW change, not any particular
> implementation, but the idea.
>
> Bitcoin is technically owned by China now. That's not acceptable.
>
> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi all,
>
> Feedback is welcome on the draft below. In particular, I want to see if
> there is interest in further development of the idea and also interested in
> any attack vectors or undesirable dynamics.
>
> (Formatted version available here:
> https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>
> # Soft-fork Introduction of a New POW
>
> ## Motivation:
>
> - Mitigate mining centralization pressures by introducing a POW that does
> not have economies of scale
> - Introduce an intermediary confirmation point, reducing the impact of
> mining power fluctuations
>
> Note however that choice of a suitable POW will require deep analysis.
> Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are
> not, unexpected/covert optimization.
>
> In particular, unexpected/covert optimizations, such as ASCIBOOST, present
> a potential centralizing and destabilizing force.
>
> ## Design
>
> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
> alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains
> transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain
> all transactions from the aux-POW block.
> Block space is not increased.
>
> The new intermediate block and the pointers are introduced via a soft-fork
> restriction.
>
> ### Reward for aux POW miners
>
> The reward for the aux POW smoothly increases from zero to a target value
> (e.g. 1/2 of the total reward) over time.
> The reward is transferred via a soft-fork restriction requiring a coinbase
> output to an address published in the
> aux-POW block.
>
> ### Aux POW difficulty adjustment
>
> Difficulty adjustments remain independent for the two POWs.
>
> The difficulty of the aux POW is adjusted based on the average time
> between normal block found
> to aux block found.
>
> Further details are dependent on the specific POW.
>
> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the
> wrong chain in case of attack. However,
> it might be possible to construct an alert system that notifies
> non-upgraded nodes of an upcoming rule change.
> All blocks are still valid, so this is not a hardforking change.
>
> The heaviest chain definition changes from sum of `difficulty` to sum of:
>
> mainDifficulty ^ x * auxDifficulty ^ y
>
> where we start at:
>
> x = 1; y = 0
>
> and end at values of x and y that are related to the target relative
> rewards. For example, if the target rewards
> are equally distributed, we will want ot end up at:
>
> x = 1/2; y = 1/2
>
> so that both POWs have equal weight. If the aux POW is to become
> dominant, x should end small relative to y.
>
>
> ## Questions and Answers
>
> - What should be the parameters if we want the aux POW to have equal
> weight? A: 1/2 of the reward should be transferred
> to aux miners and x = 1/2, y = 1/2.
>
> - What should be the parameters if we want to deprecate the main POW? A:
> most of the reward should be transferred to
> aux miners and x = 0, y = 1. The main difficulty will tend to zero, and
> aux miners will just trivially generate the
> main block immediately after finding an aux block, with identical content.
>
> - Wasted bandwidth to transfer transactions twice? A: this can be
> optimized by skipping transactions already
> transferred.
>
> - Why would miners agree to soft-fork away some of their reward? A: they
> would agree if they believe that
> the coins will increase in value due to improved security properties.
>
> ## Open Questions
>
> - After a block of one type is found, we can naively assume that POW will
> become idle while a block of the other type is being mined. In practice,
> the spare capacity can be used to find alternative ("attacking") blocks or
> mine other coins. Is that a problem?
> - Is selfish mining amplified by this scheme for miners that have both
> types of hardware?
>
> ## POW candidates
>
> - SHA256 (i.e. use same POW, but introduce an intermediate block for
> faster confirmation)
> - Proof of Space and Time (Bram Cohen)
> - Equihash
> - Ethash
>
> ## Next Steps
>
> - evaluate POW candidates
> - evaluate difficulty adjustment rules
> - simulate miner behavior to identify if there are incentives for
> detrimental behavior patterns (e.g. block withholding / selfish mining)
> - Protocol details
>
> ## Credits
>
> Bram Cohen came up with a similar idea back in March:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 9742 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-01 5:48 [bitcoin-dev] Introducing a POW through a soft-fork Devrandom
2017-11-02 23:55 ` Tao Effect
@ 2017-11-06 19:50 ` Peter Todd
2017-11-06 20:30 ` Paul Sztorc
2017-11-06 22:39 ` Devrandom
1 sibling, 2 replies; 10+ messages in thread
From: Peter Todd @ 2017-11-06 19:50 UTC (permalink / raw)
To: Devrandom, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
Some quick thoughts...
> Hi all,
>
> Feedback is welcome on the draft below. In particular, I want to see if
> there is interest in further development of the idea and also interested in
> any attack vectors or undesirable dynamics.
>
> (Formatted version available here:
> https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>
> # Soft-fork Introduction of a New POW
First of all, I don't think you can really call this a soft-fork; I'd call it a
"pseudo-soft-fork"
My reasoning being that after implementation, a chain with less total work than
the main chain - but more total SHA256^2 work than the main chain - might be
followed by non-supporting clients. It's got some properties of a soft-fork,
but it's security model is definitely different.
> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
> alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains
> transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain all
> transactions from the aux-POW block.
Note how you're basically proposing for the block interval to be decreased,
which has security implications due to increased orphan rates.
> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the wrong
> chain in case of attack. However,
Exactly! Not really a soft-fork.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-06 19:50 ` Peter Todd
@ 2017-11-06 20:30 ` Paul Sztorc
2017-11-06 20:55 ` Eric Voskuil
2017-11-06 22:39 ` Devrandom
1 sibling, 1 reply; 10+ messages in thread
From: Paul Sztorc @ 2017-11-06 20:30 UTC (permalink / raw)
To: Peter Todd, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]
+1 to all of Peter Todd's comments
On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>
> Some quick thoughts...
>
> > Hi all,
> >
> > Feedback is welcome on the draft below. In particular, I want to see if
> > there is interest in further development of the idea and also interested
> in
> > any attack vectors or undesirable dynamics.
> >
> > (Formatted version available here:
> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
> >
> > # Soft-fork Introduction of a New POW
>
> First of all, I don't think you can really call this a soft-fork; I'd call
> it a
> "pseudo-soft-fork"
>
> My reasoning being that after implementation, a chain with less total work
> than
> the main chain - but more total SHA256^2 work than the main chain - might
> be
> followed by non-supporting clients. It's got some properties of a
> soft-fork,
> but it's security model is definitely different.
>
> > ### Aux POW intermediate block
> >
> > Auxiliary POW blocks are introduced between normal blocks - i.e. the
> chain
> > alternates between the two POWs.
> > Each aux-POW block points to the previous normal block and contains
> > transactions just like a normal block.
> > Each normal block points to the previous aux-POW block and must contain
> all
> > transactions from the aux-POW block.
>
> Note how you're basically proposing for the block interval to be decreased,
> which has security implications due to increased orphan rates.
>
> > ### Heaviest chain rule change
> >
> > This is a semi-hard change, because non-upgraded nodes can get on the
> wrong
> > chain in case of attack. However,
>
> Exactly! Not really a soft-fork.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 3012 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-06 20:30 ` Paul Sztorc
@ 2017-11-06 20:55 ` Eric Voskuil
2017-11-07 4:38 ` Devrandom
0 siblings, 1 reply; 10+ messages in thread
From: Eric Voskuil @ 2017-11-06 20:55 UTC (permalink / raw)
To: Paul Sztorc, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.
e
> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> +1 to all of Peter Todd's comments
>
>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>>
>> Some quick thoughts...
>>
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below. In particular, I want to see if
>> > there is interest in further development of the idea and also interested in
>> > any attack vectors or undesirable dynamics.
>> >
>> > (Formatted version available here:
>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>> >
>> > # Soft-fork Introduction of a New POW
>>
>> First of all, I don't think you can really call this a soft-fork; I'd call it a
>> "pseudo-soft-fork"
>>
>> My reasoning being that after implementation, a chain with less total work than
>> the main chain - but more total SHA256^2 work than the main chain - might be
>> followed by non-supporting clients. It's got some properties of a soft-fork,
>> but it's security model is definitely different.
>>
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
>> > alternates between the two POWs.
>> > Each aux-POW block points to the previous normal block and contains
>> > transactions just like a normal block.
>> > Each normal block points to the previous aux-POW block and must contain all
>> > transactions from the aux-POW block.
>>
>> Note how you're basically proposing for the block interval to be decreased,
>> which has security implications due to increased orphan rates.
>>
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the wrong
>> > chain in case of attack. However,
>>
>> Exactly! Not really a soft-fork.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> 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: 4195 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-06 20:55 ` Eric Voskuil
@ 2017-11-07 4:38 ` Devrandom
2017-11-11 19:51 ` Eric Voskuil
0 siblings, 1 reply; 10+ messages in thread
From: Devrandom @ 2017-11-07 4:38 UTC (permalink / raw)
To: Eric Voskuil, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]
A hard-fork is a situation where non-upgraded nodes reject a block mined
and relayed by upgraded nodes. This creates a fork that cannot heal
regardless of what follows.
This proposal is not a hard-fork, because the non-upgraded node *will heal*
if the attack has less than 1/2 of the original-POW power in the long term.
The cost of such an attack is the cost of a normal "51%" attack, multiplied
by the fractional weight of the original POW (e.g. 0.75 or 0.5).
So rather than saying this is a hard-fork, I would say that this is a
soft-fork with reduced security for non-upgraded nodes. I would also say
that the reduction in security is proportional to the reduction in weight
of the original POW at the time of attack.
As mentioned before, the original-POW weight starts at 1.0 and is reduced
over a long period of time. I would set up the transition curve so that
all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes
protecting high economic value would upgrade early.
On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> If a block that would be discarded under previous rules becomes accepted
> after a rule addition, there is no reason to not simply call the new rule a
> hard fork. IOW it's perfectly rational to consider a weaker block as
> "invalid" relative to the strong chain. As such I don't see any reason to
> qualify the term, it's a hard fork. But Peter's observation (the specific
> behavior) is ultimately what matters.
>
> e
>
> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> +1 to all of Peter Todd's comments
>
> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>>
>> Some quick thoughts...
>>
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below. In particular, I want to see if
>> > there is interest in further development of the idea and also
>> interested in
>> > any attack vectors or undesirable dynamics.
>> >
>> > (Formatted version available here:
>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>> >
>> > # Soft-fork Introduction of a New POW
>>
>> First of all, I don't think you can really call this a soft-fork; I'd
>> call it a
>> "pseudo-soft-fork"
>>
>> My reasoning being that after implementation, a chain with less total
>> work than
>> the main chain - but more total SHA256^2 work than the main chain - might
>> be
>> followed by non-supporting clients. It's got some properties of a
>> soft-fork,
>> but it's security model is definitely different.
>>
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the
>> chain
>> > alternates between the two POWs.
>> > Each aux-POW block points to the previous normal block and contains
>> > transactions just like a normal block.
>> > Each normal block points to the previous aux-POW block and must contain
>> all
>> > transactions from the aux-POW block.
>>
>> Note how you're basically proposing for the block interval to be
>> decreased,
>> which has security implications due to increased orphan rates.
>>
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the
>> wrong
>> > chain in case of attack. However,
>>
>> Exactly! Not really a soft-fork.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> _______________________________________________
>> 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: 6151 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-07 4:38 ` Devrandom
@ 2017-11-11 19:51 ` Eric Voskuil
0 siblings, 0 replies; 10+ messages in thread
From: Eric Voskuil @ 2017-11-11 19:51 UTC (permalink / raw)
To: Devrandom; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 6349 bytes --]
> On Nov 6, 2017, at 20:38, Devrandom <c1.bitcoin@niftybox•net> wrote:
>
> A hard-fork is a situation where non-upgraded nodes reject a block mined and relayed by upgraded nodes.
As Peter pointed out, that is the case here.
> This creates a fork that cannot heal regardless of what follows.
That is not a condition of the hard fork concept.
https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
Softfork
A consensus fork wherein everything that was previously invalid remains invalid while blocks that would have previously considered valid become invalid. A hashrate majority of miners can impose the new rules. They have some deployment advantages like backward compatibility.
Hardfork
A consensus fork that makes previously invalid blocks valid. Hardforks require all users to upgrade.
The essential element of a hard fork is that the new rule may cause rejection of blocks that are not rejected by old rules (thereby requiring that all users adopt the new rule in order to avoid a split). The reason a hard fork is interesting is that it can create a chain split even if it is enforced by majority hash power.
That is not the case with a soft fork and it is not the case here. A split can occur. The fact that it is possible for the split to also eventually orphan the old nodes does not make it a soft fork. A soft fork requires that a hash power majority can impose the rule. However, under the proposed new rule the hash power majority (according to the new rule) cannot impose the rule on existing nodes.
> This proposal is not a hard-fork, because the non-upgraded node *will heal* if the attack has less than 1/2 of the original-POW power in the long term.
Nothing about this proposal implies an attack. From the Motivation section:
Mitigate centralization pressures by introducing a POW that does not have economies of scale
Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations
> The cost of such an attack is the cost of a normal "51%" attack, multiplied by the fractional weight of the original POW (e.g. 0.75 or 0.5).
>
> So rather than saying this is a hard-fork, I would say that this is a soft-fork with reduced security for non-upgraded nodes.
Presumably this preference exists because it implies the new rule would not cause a chain split, making it more acceptable to a risk-averse economy. This is precisely why it should be described correctly.
> I would also say that the reduction in security is proportional to the reduction in weight of the original POW at the time of attack.
>
> As mentioned before, the original-POW weight starts at 1.0 and is reduced over a long period of time. I would set up the transition curve so that all nodes upgrade by the time the weight is, say, 0.75. In reality, nodes protecting high economic value would upgrade early.
In reality you have no way to know if/when people would adopt this rule. What matters in the proposal is that people who do adopt it are well aware of its ability to split them from the existing economy.
e
>> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.
>>
>> e
>>
>>> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> +1 to all of Peter Todd's comments
>>>
>>>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>>>>
>>>> Some quick thoughts...
>>>>
>>>> > Hi all,
>>>> >
>>>> > Feedback is welcome on the draft below. In particular, I want to see if
>>>> > there is interest in further development of the idea and also interested in
>>>> > any attack vectors or undesirable dynamics.
>>>> >
>>>> > (Formatted version available here:
>>>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>>>> >
>>>> > # Soft-fork Introduction of a New POW
>>>>
>>>> First of all, I don't think you can really call this a soft-fork; I'd call it a
>>>> "pseudo-soft-fork"
>>>>
>>>> My reasoning being that after implementation, a chain with less total work than
>>>> the main chain - but more total SHA256^2 work than the main chain - might be
>>>> followed by non-supporting clients. It's got some properties of a soft-fork,
>>>> but it's security model is definitely different.
>>>>
>>>> > ### Aux POW intermediate block
>>>> >
>>>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
>>>> > alternates between the two POWs.
>>>> > Each aux-POW block points to the previous normal block and contains
>>>> > transactions just like a normal block.
>>>> > Each normal block points to the previous aux-POW block and must contain all
>>>> > transactions from the aux-POW block.
>>>>
>>>> Note how you're basically proposing for the block interval to be decreased,
>>>> which has security implications due to increased orphan rates.
>>>>
>>>> > ### Heaviest chain rule change
>>>> >
>>>> > This is a semi-hard change, because non-upgraded nodes can get on the wrong
>>>> > chain in case of attack. However,
>>>>
>>>> Exactly! Not really a soft-fork.
>>>>
>>>> --
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>>
>>>> _______________________________________________
>>>> 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: 10479 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [bitcoin-dev] Introducing a POW through a soft-fork
2017-11-06 19:50 ` Peter Todd
2017-11-06 20:30 ` Paul Sztorc
@ 2017-11-06 22:39 ` Devrandom
2017-11-06 23:38 ` Devrandom
1 sibling, 1 reply; 10+ messages in thread
From: Devrandom @ 2017-11-06 22:39 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]
Hi Peter, thank you for the review. See below
On Mon, Nov 6, 2017 at 11:50 AM Peter Todd <pete@petertodd•org> wrote:
> On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
>
> Some quick thoughts...
>
> > Hi all,
> >
> > Feedback is welcome on the draft below. In particular, I want to see if
> > there is interest in further development of the idea and also interested
> in
> > any attack vectors or undesirable dynamics.
> >
> > (Formatted version available here:
> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
> >
> > # Soft-fork Introduction of a New POW
>
> First of all, I don't think you can really call this a soft-fork; I'd call
> it a
> "pseudo-soft-fork"
>
> My reasoning being that after implementation, a chain with less total work
> than
> the main chain - but more total SHA256^2 work than the main chain - might
> be
> followed by non-supporting clients. It's got some properties of a
> soft-fork,
> but it's security model is definitely different.
>
The interesting thing is that the cost of attack varies smoothly as you
vary the POW weights.
To attack non-upgraded nodes, you still have to "51%" the original POW.
The reward going to that POW will vary smoothly between 1.0 * block_reward
and whatever
target value (e.g. 0.5 * block_reward) and the difficulty of attack will
tend to be proportional to that.
In a real hard-fork, your software just breaks at the fork point. In this
case, it's just the non-upgraded
node security level declining from 100% to 50% over a long period of time.
I envision the transition of POW weights will be over 1-3 years, which
leaves plenty of time to
upgrade after the fork activates.
>
> > ### Aux POW intermediate block
> >
> > Auxiliary POW blocks are introduced between normal blocks - i.e. the
> chain
> > alternates between the two POWs.
> > Each aux-POW block points to the previous normal block and contains
> > transactions just like a normal block.
> > Each normal block points to the previous aux-POW block and must contain
> all
> > transactions from the aux-POW block.
>
> Note how you're basically proposing for the block interval to be decreased,
> which has security implications due to increased orphan rates.
>
Note that the total transaction rate and block size don't materially
change, so I don't
see why the orphan rate will change. Normal blocks are constrained to have
all of the txs of the aux blocks, so propagation time should stay the
same. Am I missing
something?
>
> > ### Heaviest chain rule change
> >
> > This is a semi-hard change, because non-upgraded nodes can get on the
> wrong
> > chain in case of attack. However,
>
> Exactly! Not really a soft-fork.
>
"smooth-fork" perhaps? :)
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
[-- Attachment #2: Type: text/html, Size: 4127 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-11-11 19:51 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-01 5:48 [bitcoin-dev] Introducing a POW through a soft-fork Devrandom
2017-11-02 23:55 ` Tao Effect
2017-11-03 1:02 ` Devrandom
2017-11-06 19:50 ` Peter Todd
2017-11-06 20:30 ` Paul Sztorc
2017-11-06 20:55 ` Eric Voskuil
2017-11-07 4:38 ` Devrandom
2017-11-11 19:51 ` Eric Voskuil
2017-11-06 22:39 ` Devrandom
2017-11-06 23:38 ` Devrandom
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox