Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Ben Kloester via bitcoin-dev]

Is there a contingency plan in the case that the incumbent chain following
the Bitcoin Core consensus rules comes under 51% attack?

If the 2x fork really does have the support of >66% of miners (which
remains to be seen), it seems like they'd have spare capacity to perform
such an attack. In which case, a rushed hard fork might be the only option
to guarantee the survival of the chain, would it not?

I'm aware of Luke's work on BitcoinHardfork
, but not aware of whether this has
actually been tested in the field by anyone - ie whether anyone actually
has even run the code much / created a testnet. What are the options for an
emergency hard fork, and how much testing has each seen?

*Ben Kloester*

On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem of fast acting but non vulnerable difficulty adjustment
> algorithms is interesting. I would certainly like to see this space further
> explored, and even have some ideas myself.
>
> However without commenting on the technical merits of this specific
> proposal, I think it must be said upfront that the stated goal is not good.
> The largest technical concern (ignoring governance) over B2X is that it is
> a rushed, poorly reviewed hard fork. Hard forks should not be rushed, and
> they should receive more than the usual level of expert and community
> review.
>
> I’m that light, doing an even more rushed hard fork on an even newer idea
> with even less review would be hypocritical at best. I would suggest
> reframing as a hardfork wishlist research problem for the next properly
> planned hard fork, if one occurs. You might also find the hardfork research
> group a more accommodating venue for this discussion:
>
> https://bitcoinhardforkresearch.github.io/
>
> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Sorry, my previous email did not have the plain text I intended.
>
> Background:
>
> The bitcoin difficulty algorithm does not seem to be a good one. If there
> is a fork due to miners seeking maximum profit without due regard to
> security, users, and nodes, the "better" coin could end up being the
> minority chain. If 90% of hashrate is really going to at least initially
> go
> towards using SegWit2x, BTC would face 10x delays in confirmations
> until the next difficulty adjustment, negatively affecting its price
> relative
> to BTC1, causing further delays from even more miner abandonment
> (until the next adjustment). The 10% miners remaining on BTC do not
> inevitably lose by staying to endure 10x delays because they have 10x
> less competition, and the same situation applies to BTC1 miners. If the
> prices are the same and stable, all seems well for everyone, other things
> aside. But if the BTC price does not fall to reflect the decreased
> hashrate,
> he situation seems to be a big problem for both coins: BTC1 miners will
> jump back to BTC when the difficulty adjustment occurs, initiating a
> potentially never-ending oscillation between the two coins, potentially
> worse than what BCH is experiencing.  They will not issue coins too fast
> like BCH because that is a side effect of the asymmetry in BCH's rise and
> fall algorithm.
>
> Solution:
>
> Hard fork to implement a new difficulty algorithm that uses a simple
> rolling
> average with a much smaller window.  Many small coins have done this as
> a way to stop big miners from coming on and then suddenly leaving, leaving
> constant miners stuck with a high difficulty for the rest of a (long)
> averaging
> window.  Even better, adjust the reward based on recent solvetimes to
> motivate more mining (or less) if the solvetimes are too slow (or too
> fast).
> This will keep keep coin issuance rate perfectly on schedule with real
> time.
>
> I recommend the following for Bitcoin, as fast, simple, and better than
> any
> other difficulty algorithm I'm aware of.  This is the result of a lot of
> work the
> past year.
>
> === Begin difficulty algorithm ===
> # Zawy v6 difficulty algorithm (modified for bitcoin)
> # Unmodified Zawy v6 for alt coins:
> # http://zawy1.blogspot.com/2017/07/best-difficulty-
> algorithm-zawy-v1b.html
> # All my failed attempts at something better:
> # https://github.com/seredat/karbowanec/commit/
> 231db5270acb2e673a641a1800be910ce345668a
> #
> # Keep negative solvetimes to correct bad timestamps.
> # Do not be tempted to use:
> # next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
> # ST= Solvetime, TS = timestamp
>
> # set constants until next hard fork:
>
> T=600; # coin's TargetSolvetime
> N=30; # Averaging window. Smoother than N=15, faster response than N=60.
> X=5;
> limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
> adjust = 1/(1+0.67/N);  # keeps avg solvetime on track
>
> # begin difficulty algorithm
>
> avg_ST=0; avg_D=0;
> for ( i=height;  i > height-N;  i--) {  

Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Mark Friedenbach via bitcoin-dev]

The problem of fast acting but non vulnerable difficulty adjustment algorithms 
is interesting. I would certainly like to see this space further explored, and 
even have some ideas myself.

However without commenting on the technical merits of this specific proposal, I 
think it must be said upfront that the stated goal is not good. The largest 
technical concern (ignoring governance) over B2X is that it is a rushed, poorly 
reviewed hard fork. Hard forks should not be rushed, and they should receive 
more than the usual level of expert and community review.

I’m that light, doing an even more rushed hard fork on an even newer idea with 
even less review would be hypocritical at best. I would suggest reframing as a 
hardfork wishlist research problem for the next properly planned hard fork, if 
one occurs. You might also find the hardfork research group a more 
accommodating venue for this discussion:

https://bitcoinhardforkresearch.github.io/

> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev 
>  wrote:
> 
> Sorry, my previous email did not have the plain text I intended.
> 
> Background: 
> 
> The bitcoin difficulty algorithm does not seem to be a good one. If there 
> is a fork due to miners seeking maximum profit without due regard to 
> security, users, and nodes, the "better" coin could end up being the 
> minority chain. If 90% of hashrate is really going to at least initially go 
> towards using SegWit2x, BTC would face 10x delays in confirmations 
> until the next difficulty adjustment, negatively affecting its price relative 
> to BTC1, causing further delays from even more miner abandonment 
> (until the next adjustment). The 10% miners remaining on BTC do not 
> inevitably lose by staying to endure 10x delays because they have 10x 
> less competition, and the same situation applies to BTC1 miners. If the 
> prices are the same and stable, all seems well for everyone, other things 
> aside. But if the BTC price does not fall to reflect the decreased hashrate, 
> he situation seems to be a big problem for both coins: BTC1 miners will 
> jump back to BTC when the difficulty adjustment occurs, initiating a 
> potentially never-ending oscillation between the two coins, potentially 
> worse than what BCH is experiencing.  They will not issue coins too fast 
> like BCH because that is a side effect of the asymmetry in BCH's rise and 
> fall algorithm. 
> 
> Solution: 
> 
> Hard fork to implement a new difficulty algorithm that uses a simple rolling 
> average with a much smaller window.  Many small coins have done this as 
> a way to stop big miners from coming on and then suddenly leaving, leaving 
> constant miners stuck with a high difficulty for the rest of a (long) 
> averaging 
> window.  Even better, adjust the reward based on recent solvetimes to 
> motivate more mining (or less) if the solvetimes are too slow (or too fast). 
> This will keep keep coin issuance rate perfectly on schedule with real time. 
> 
> I recommend the following for Bitcoin, as fast, simple, and better than any 
> other difficulty algorithm I'm aware of.  This is the result of a lot of work 
> the 
> past year. 
> 
> === Begin difficulty algorithm === 
> # Zawy v6 difficulty algorithm (modified for bitcoin) 
> # Unmodified Zawy v6 for alt coins: 
> # http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html 
> # All my failed attempts at something better: 
> # 
> https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a
>  
> # 
> # Keep negative solvetimes to correct bad timestamps. 
> # Do not be tempted to use: 
> # next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]; 
> # ST= Solvetime, TS = timestamp 
> 
> # set constants until next hard fork: 
> 
> T=600; # coin's TargetSolvetime 
> N=30; # Averaging window. Smoother than N=15, faster response than N=60. 
> X=5; 
> limit = X^(2/N); # limit rise and fall in case of timestamp manipulation 
> adjust = 1/(1+0.67/N);  # keeps avg solvetime on track 
> 
> # begin difficulty algorithm 
> 
> avg_ST=0; avg_D=0; 
> for ( i=height;  i > height-N;  i--) {  # go through N most recent blocks 
> avg_ST += (TS[i] - TS[i-1]) / N; 
> avg_D += D[i]/N; 
> } 
> avg_ST = T*limit if avg_ST > T*limit; 
> avg_ST = T/limit if avg_ST < T/limit; 
> 
> next_D = avg_D * T / avg_ST * adjust; 
> 
> # Tim Olsen suggested changing reward to protect against hash attacks. 
> # Karbowanek coin suggested something similar. 
> # I could not find anything better than the simplest idea below. 
> # It was a great surprise that coin issuance rate came out perfect. 
> # BaseReward = coins per block 
> 
> next_reward = BaseReward * avg_ST / T; 
> 
> === end algo  
> 
> Due to the limit and keeping negative solvetimes in a true average, 
> timestamp errors resulting in negative solvetimes are corrected in the next 
> block. Otherwise, one would need to do like Zcash and cause a 5-block 
> delay 

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Paul Sztorc via bitcoin-dev]

That is only a one-way peg, not a two-way.

In fact, that is exactly what drivechain does, if one chooses parameters
for the drivechain that make it impossible for any side-to-main transfer to
succeed.

One-way pegs have strong first-mover disadvantages.

Paul

On Oct 9, 2017 9:24 PM, "Tao Effect via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

Dear list,

In previous arguments over Drivechain (and Drivechain-like proposals) I
promised that better scaling proposals — that do not sacrifice Bitcoin's
security — would come along.

I planned to do a detailed writeup, but have decided to just send off this
email with what I have, because I'm unlikely to have time to write up a
detailed proposal.

The idea is very simple (and by no means novel*), and I'm sure others have
mentioned either exactly it, or similar ideas (e.g. burning coins) before.

This is a generic sharding protocol for all blockchains, including Bitcoin.

Users simply say: "My coins on Chain A are going to be sent to Chain B".

Then they burn the coins on Chain A, and create a minting transaction on
Chain B. The details of how to ensure that coins do not get lost needs to
be worked out, but I'm fairly certain the folks on this list can figure out
those details.

- Thin clients, nodes, and miners, can all very easily verify that said
action took place, and therefore accept the "newly minted" coins on B as
valid.
- Users client software now also knows where to look for the other coins
(if for some reason it needs to).

This doesn't even need much modification to the Bitcoin protocol as most of
the verification is done client-side.

It is fully decentralized, and there's no need to give our ownership of our
coins to miners to get scale.

My sincere apologies if this has been brought up before (in which case, I
would be very grateful for a link to the proposal).

Cheers,
Greg Slepak

* This idea is similar in spirit to Interledger.

--
Please do not email me anything that you are not comfortable also sharing with
the NSA.


___
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] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

[Tao Effect via bitcoin-dev]

Dear list,

In previous arguments over Drivechain (and Drivechain-like proposals) I 
promised that better scaling proposals — that do not sacrifice Bitcoin's 
security — would come along.

I planned to do a detailed writeup, but have decided to just send off this 
email with what I have, because I'm unlikely to have time to write up a 
detailed proposal.

The idea is very simple (and by no means novel*), and I'm sure others have 
mentioned either exactly it, or similar ideas (e.g. burning coins) before.

This is a generic sharding protocol for all blockchains, including Bitcoin.

Users simply say: "My coins on Chain A are going to be sent to Chain B".

Then they burn the coins on Chain A, and create a minting transaction on Chain 
B. The details of how to ensure that coins do not get lost needs to be worked 
out, but I'm fairly certain the folks on this list can figure out those details.

- Thin clients, nodes, and miners, can all very easily verify that said action 
took place, and therefore accept the "newly minted" coins on B as valid.
- Users client software now also knows where to look for the other coins (if 
for some reason it needs to).

This doesn't even need much modification to the Bitcoin protocol as most of the 
verification is done client-side.

It is fully decentralized, and there's no need to give our ownership of our 
coins to miners to get scale.

My sincere apologies if this has been brought up before (in which case, I would 
be very grateful for a link to the proposal).

Cheers,
Greg Slepak

* This idea is similar in spirit to Interledger.

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

[Scott Roberts via bitcoin-dev]

Sorry, my previous email did not have the plain text I intended.

Background: 

The bitcoin difficulty algorithm does not seem to be a good one. If there 
is a fork due to miners seeking maximum profit without due regard to 
security, users, and nodes, the "better" coin could end up being the 
minority chain. If 90% of hashrate is really going to at least initially go 
towards using SegWit2x, BTC would face 10x delays in confirmations 
until the next difficulty adjustment, negatively affecting its price relative 
to BTC1, causing further delays from even more miner abandonment 
(until the next adjustment). The 10% miners remaining on BTC do not 
inevitably lose by staying to endure 10x delays because they have 10x 
less competition, and the same situation applies to BTC1 miners. If the 
prices are the same and stable, all seems well for everyone, other things 
aside. But if the BTC price does not fall to reflect the decreased hashrate, 
he situation seems to be a big problem for both coins: BTC1 miners will 
jump back to BTC when the difficulty adjustment occurs, initiating a 
potentially never-ending oscillation between the two coins, potentially 
worse than what BCH is experiencing.  They will not issue coins too fast 
like BCH because that is a side effect of the asymmetry in BCH's rise and 
fall algorithm. 

Solution: 

Hard fork to implement a new difficulty algorithm that uses a simple rolling 
average with a much smaller window.  Many small coins have done this as 
a way to stop big miners from coming on and then suddenly leaving, leaving 
constant miners stuck with a high difficulty for the rest of a (long) averaging 
window.  Even better, adjust the reward based on recent solvetimes to 
motivate more mining (or less) if the solvetimes are too slow (or too fast). 
This will keep keep coin issuance rate perfectly on schedule with real time. 

I recommend the following for Bitcoin, as fast, simple, and better than any 
other difficulty algorithm I'm aware of.  This is the result of a lot of work 
the 
past year. 

=== Begin difficulty algorithm === 
# Zawy v6 difficulty algorithm (modified for bitcoin) 
# Unmodified Zawy v6 for alt coins: 
# http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html 
# All my failed attempts at something better: 
# 
https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a
 
# 
# Keep negative solvetimes to correct bad timestamps. 
# Do not be tempted to use: 
# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]; 
# ST= Solvetime, TS = timestamp 

# set constants until next hard fork: 

T=600; # coin's TargetSolvetime 
N=30; # Averaging window. Smoother than N=15, faster response than N=60. 
X=5; 
limit = X^(2/N); # limit rise and fall in case of timestamp manipulation 
adjust = 1/(1+0.67/N);  # keeps avg solvetime on track 

# begin difficulty algorithm 

avg_ST=0; avg_D=0; 
for ( i=height;  i > height-N;  i--) {  # go through N most recent blocks 
avg_ST += (TS[i] - TS[i-1]) / N; 
avg_D += D[i]/N; 
} 
avg_ST = T*limit if avg_ST > T*limit; 
avg_ST = T/limit if avg_ST < T/limit; 

next_D = avg_D * T / avg_ST * adjust; 

# Tim Olsen suggested changing reward to protect against hash attacks. 
# Karbowanek coin suggested something similar. 
# I could not find anything better than the simplest idea below. 
# It was a great surprise that coin issuance rate came out perfect. 
# BaseReward = coins per block 

next_reward = BaseReward * avg_ST / T; 

=== end algo  

Due to the limit and keeping negative solvetimes in a true average, 
timestamp errors resulting in negative solvetimes are corrected in the next 
block. Otherwise, one would need to do like Zcash and cause a 5-block 
delay in the response by resorting to the median of past 11 blocks (MPT) 
as the most recent timestamp, offsetting the timestamps from their 
corresponding difficulties by 5 blocks. (it does not cause an averaging 
problem, but it does cause a 5-block delay in the response.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] New difficulty algorithm needed for SegWit2x fork?

[Scott Roberts via bitcoin-dev]

Background:
The bitcoin difficulty algorithm does not seem to be a good one.  If there is a 
fork due to miners seeking maximum profit without due regard to security, 
users, and nodes, the "better" coin could end up being the minority chain. If 
90% of hashrate is really going to at least initially go towards using 
SegWit2x, BTC would face 10x delays in confirmations until the next difficulty 
adjustment, negatively affecting its price relative to BTC1, causing further 
delays from even more miner abandonment (until the next adjustment). The 10% 
miners remaining on BTC do not inevitably lose by staying to endure 10x delays 
because they have 10x less competition, and the same situation applies to BTC1 
miners. If the prices are the same and stable, all seems well for everyone, 
other things aside.  But if the BTC price does not fall to reflect the 
decreased hashrate, the situation seems to be a big problem for both coins: 
BTC1 miners will jump back to BTC when the difficulty adjustment occurs, 
initiating a potentially never-ending oscillation between the two coins, 
potentially worse than what BCH is experiencing.  They will not issue coins too 
fast like BCH because that is a side effect of the asymmetry in BCH's rise and 
fall algorithm.
Solution:
Hard fork to implement a new difficulty algorithm that uses a simple rolling 
average with a much smaller window.  Many small coins have done this as a way 
to stop big miners from coming on and then suddenly leaving, leaving constant 
miners stuck with a high difficulty for the rest of a (long) averaging window.  
Even better, adjust the reward based on recent solvetimes to motivate more 
mining (or less) if the solvetimes are too slow (or too fast).  This will keep 
keep the coin issuance rate perfectly on schedule with real time. 
I recommend the following for Bitcoin, as fast, simple, and better than any 
other difficulty algorithm I'm aware of.  This is the result of a lot of work 
the past year.
=== Begin difficulty algorithm ===# Zawy v6 difficulty algorithm (modified for 
bitcoin)# Unmodified Zawy v6 for alt coins: # 
http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html# My 
failed attempts at something better:# 
https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a##
 Keep negative solvetimes to correct bad timestamps.# Do not be tempted to 
use:# next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];# 
D=difficulty, ST= Solvetime, TS = timestamp, T=TargetSolveTime
# set constants until next hard fork:
T=600; N=30; # Averaging window. Smoother than N=15, faster response than 
N=60.X=5; # size of sudden hashrate changes expected as multiple of base 
hashrate.limit = X^(2/N); # limit rise and fall to protect against timestamp 
errors & manipulationadjust = 1/(1+0.67/N);  # keeps avg solvetime on track for 
small N.
# begin difficulty algorithm 
avg_ST=0; # avg SolveTimeavg_D=0;for ( i=height;  i > height-N;  i--) {  # go 
through N most recent blocks   avg_ST += (TS[i] - TS[i-1]) / N; # TS=timestamps 
  avg_D += D[i]/N;}avg_ST = T*limit if avg_ST > T*limit; avg_ST = T/limit if 
avg_ST < T/limit; 
next_D = avg_D * T / avg_ST * adjust; 
# Tim Olsen suggested changing coin reward to protect against hash attacks.# 
Karbowanek coin suggested something similar.# After testing many ideas, I could 
not find anything better than the simplest idea below.# It was a surprise that 
coin issuance rate came out perfect.# BaseReward = coins per block
next_reward = BaseReward * avg_ST / T;
=== end algo 
Due to the limit and keeping negative solvetimes in a true average, timestamp 
errors resulting in negative solvetimes are corrected in the next block. 
Otherwise, one would need to do like Zcash and cause a 5-block delay in the 
response by resorting to the median of past 11 blocks (MTP) as the most recent 
timestamp, offsetting the timestamps from their corresponding difficulties by 5 
blocks. (it does not cause an averaging problem, but it does cause a 5-block 
delay in the response.)
Small N windows like keep the correct median, but cause avg solvetime to be 
above the target. The "adjust" constant (empirically determined) fixes this, 
but it causes the median to be that same percentage too low, below the ideal 
Poisson median which is 0.693 of the mean. I was not able to find a fix to this 
that did not slow down the response to hashrate changes.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev