Ben Kloester [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-10-10 to 2018-01-08
💬 Posted a total of 5 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:09:27

- reply

📅 Original date posted:2018-01-08
📝 Original message:> This sounds very dangerous. As Gregory Maxwell pointed out, the key
derivation
> function is weak enough that passphrases could be easily brute forced
So you are essentially imagining that a perpetrator will combine the
crypto-nerd fantasy (brute forcing the passphrase) *with* the 5-dollar
wrench attack, merging both panes of Randall Munroe's comic? Seems
vanishingly unlikely to me - attackers are generally either the wrench
type, or the crypto-nerd type.
This thread started by you asking Pavol to give an example of a real-life
scenario in which this functionality would be used, and your rebuttal is a
scenario that is even less likely to occur. "Very dangerous" is a huge
stretch.
When living in Brazil I often carried two (IRL) wallets - one a decoy to
give to muggers, the other with more value stored in it. I heard of plenty
of people getting mugged, but I never heard of anyone who gave a decoy
wallet getting more thoroughly searched and the second wallet found,
despite the relative ease with which a mugger could do this. I'm sure it
has happened, probably many times, but point is there is rarely time for
contemplation in a shakedown, and most perpetrators will take things at
face value and be satisfied with getting something. And searching a
physical person's body is a hell of a lot simpler than cracking a
passphrase.
Moreover, there's no limit to the number of passphrases you can use. If you
were an atttacker, at what point would you stop, satisfied? After the
first, second, third, fourth wallet that you find/they admit to owning?
Going beyond two is already Bond-supervillain level implausible.
*Ben Kloester*
On 9 January 2018 at 06:37, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Jan 08, 2018 at 02:00:17PM +0100, Pavol Rusnak wrote:
> > On 08/01/18 13:45, Peter Todd wrote:
> > > Can you explain _exactly_ what scenario the "plausible deniability"
> feature
> > > refers to?
> >
> >
> > https://doc.satoshilabs.com/trezor-user/advanced_settings.
> html#multi-passphrase-encryption-hidden-wallets
>
> This sounds very dangerous. As Gregory Maxwell pointed out, the key
> derivation
> function is weak enough that passphrases could be easily brute forced, at
> which
> point the bad guys have cryptographic proof that you tried to lie to them
> and
> cover up funds.
>
>
> What model of human memory are you assuming here? What specifically are you
> assuming is easy to remember, and hard to remember? What psychology
> research
> backs up your assumptions?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180109/4701a311/attachment.html>

2023-06-07 20:07:57

- reply

📅 Original date posted:2017-11-30
📝 Original message:Something similar to this has been proposed in this article by Ron Lavi,
Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015093.html
They only discussed changing the fee structure, not removing the block size
limit, as far as I know.
"Redesigning Bitcoin's fee market"
https://arxiv.org/abs/1709.08881
*Ben Kloester*
On 30 November 2017 at 11:47, William Morriss via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Comrades,
>
> Long term, tx fees must support hash power by themselves. The following is
> an economic approach to maximize total fee collection, and therefore
> hashpower.
>
> *Goals*
> Maximize total transaction fees
> Reduce pending transaction time
> Reduce individual transaction fees
>
> *Challenges*
> Validators must agree on the maximum block size, else miners can cheat and
> include extra transactions.
> Allowing too many transactions per block will increase the cost of the
> mining without collecting much income for the network.
>
>
> *Problem*
> In the transaction market, users are the demand curve, because they will
> transact less when fees are higher, and prefer altcoins. The block size is
> the supply curve, because it represents miners' willingness to accept
> transactions.
> Currently, the supply curve is inelastic:
>
> Increasing the block size will not affect the inelasticity for any fixed
> block size. The downsides of a fixed block size limit are well-known:
> - Unpredictable transaction settlement time
> - Variable transaction fees depending on network congestion
> - Frequent overpay
>
> *Proposal*
> 1. Miners implicitly choose the market sat/byte rate with the cheapest-fee
> transaction included in their block. Excess transaction fees are refunded
> to the inputs.
> 2. Remove the block size limit, which is no longer necessary.
>
> *Benefits*
> - Dynamic block size limit regulated by profit motive
> - Transaction fees maximized for every block
> - No overpay; all fees are fair
>
> Miners individually will make decisions to maximize their block-reward
> profit.
> Miners are incentivized to ignore low-fee transactions because they would
> shave the profits of their other transactions and increase their hash time.
> Users and services are free to bid higher transaction fees in order to
> reach the next block, since their excess bid will be refunded.
>
> The block size limit was added as a spam-prevention measure, but in order
> for an attacker to spam the network with low-fee transactions, they would
> have to offset the marginal cost of reducing the price with their own
> transaction fees. Anti-spam is thus built into the marginal system without
> the need for an explicit limit.
>
> Rarely, sections of the backlog would become large enough to be
> profitable. This means every so many blocks, lower-fee transactions would
> be included en masse after having been ignored long enough. Low-fee
> transactions thus gain a liveness property not previously enjoyed: low-fee
> transactions will eventually confirm. Miners targeting these transactions
> would be at a noteworthy disadvantage because they would be hashing a
> larger block. I predict that this scheme would result in two markets: a
> backlog market and a real-time market. Users targeting the backlog market
> would match the price of the largest backlog section in order to be
> included in the next backlog block.
>
> *Examples*
>
> Scenario 1
> Sat/byte Bytes Reward
> 400 500000 200000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1500000 150000000
> 50 5000000 250000000
> 20 10000000 200000000
> A miner would create a 5MB block and receive 0.25 BTC
>
> Scenario 2
> Sat/byte Bytes Reward
> 400 600000 240000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1800000 180000000
> 50 4000000 200000000
> 20 10000000 200000000
> A miner would create a 600KB block and receive 0.24 BTC
>
> Thanks,
> William Morriss
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marginal.png
Type: image/png
Size: 21403 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0005.png>

2023-06-07 20:07:05

- reply

📅 Original date posted:2017-10-10
📝 Original message:I don't get it. At the moment, the number of Bitcoin is fixed (at 21
million) by the geometric decay of the block reward.
Adding any other means of creating coins besides the existing block reward,
or altering the block reward schedule, is extremely likely to be seen as
messing with fixed supply. And not adding another method to create coins
wouldn't work - because then redemptions would have to come out of miner's
block reward, which I don't imagine they're going to share just because you
ask.
The only way you might convince users that adding a second way to mint
coins is not messing with fixed supply, is if there is some kind of proof
that the number of coins being minted is accounted for by past burnt coins.
We could call this 'regeneration'. But then you also need a way to prevent
double-regeneration, in which the same burnt coins are used as proof twice.
And you would also need per-sidechain accounting, so that you can't just
regenerate burnt coins that were originally burnt for sidechain A when all
you have is coins on sidechain B. But where to put all this logic? Building
a system that enforces the accounting for sidechains into Bitcoin, as Lucas
pointed out, is not much different to just building the sidechain itself
directly into Bitcoin.
And if you did assemble all that, what you have anyway is a two way peg,
which I suspect will be isomorphic to the very sidechain proposals you seem
to be criticising/attempting to do better than.
*Ben Kloester*
On 11 October 2017 at 07:43, Tao Effect via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> What?
>
> That is not correct.
>
> There is a fixed amount of Bitcoin, as I said.
>
> The only difference is what chain it is on.
>
> It is precisely because there is a fixed amount that when you
> burn-to-withdraw you mint on another chain.
>
> I will not respond to any more emails unless they’re from core developers.
> Gotta run.
>
> --
> Sent from my mobile device.
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> > On Oct 10, 2017, at 1:23 PM, James Hudon <jameshudon at gmail.com> wrote:
> >
> > You're asking for newly minted bitcoin to go to you but you burned the
> bitcoin used in the peg. You're effectively losing your money and then
> stealing from the miners to gain it back. The miners had to issue your
> amount of bitcoin 2 times (once for your original bitcoin, again to make
> you whole). Why would they agree to this?
> > --
> > hudon
> >
> >> On Oct 10, 2017, at 13:13, Tao Effect via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> It would not change the number of Bitcoins in existence.
> >>
> >> --
> >> Sent from my mobile device.
> >> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>
> >>> On Oct 10, 2017, at 12:50 PM, CryptAxe <cryptaxe at gmail.com> wrote:
> >>>
> >>> Your method would change the number of Bitcoins in existence. Why?
> >>>
> >>> On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> Is that what passes for a technical argument these days? Sheesh.
> >>>
> >>> Whereas in Drivechain users are forced to give up their coins to a
> single group for whatever sidechains they interact with, the generic
> sharding algo lets them (1) keep their coins, (2) trust whatever group they
> want to trust (the miners of the various sidechains).
> >>>
> >>> Drivechain offers objectively worse security.
> >>>
> >>> --
> >>> Sent from my mobile device.
> >>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>
> >>>> On Oct 10, 2017, at 8:09 AM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>>
> >>>> I think this response speaks for itself.
> >>>>
> >>>>> On 10/10/2017 10:09 AM, Tao Effect wrote:
> >>>>> Hi Paul,
> >>>>>
> >>>>> I thought it was clear, but apparently you are getting stuck on the
> semantics of the word "burn".
> >>>>>
> >>>>> The "burning" applies to the original coins you had.
> >>>>>
> >>>>> When you transfer them back, you get newly minted coins, equivalent
> to the amount you "burned" on the chain you're transferring from ― as
> stated in the OP.
> >>>>>
> >>>>> If you don't like the word "burn", pick another one.
> >>>>>
> >>>>> --
> >>>>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>>>
> >>>>>> On Oct 10, 2017, at 4:20 AM, Paul Sztorc <truthcoin at gmail.com>
> wrote:
> >>>>>>
> >>>>>> Haha, no. Because you "burned" the coins.
> >>>>>>
> >>>>>> On Oct 10, 2017 1:20 AM, "Tao Effect" <contact at taoeffect.com>
> wrote:
> >>>>>> Paul,
> >>>>>>
> >>>>>> It's a two-way peg.
> >>>>>>
> >>>>>> There's nothing preventing transfers back to the main chain.
> >>>>>>
> >>>>>> They work in the exact same manner.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Greg
> >>>>>>
> >>>>>> --
> >>>>>> Please do not email me anything that you are not comfortable also
> sharing with the NSA.
> >>>>>>
> >>>>>>> On Oct 9, 2017, at 6:39 PM, Paul Sztorc <truthcoin at gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> 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 at 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 at lists.linuxfoundation.org
> >>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> bitcoin-dev mailing list
> >>>> bitcoin-dev at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171011/3aecf220/attachment-0001.html>

2023-06-07 20:06:55

- reply

📅 Original date posted:2017-10-10
📝 Original message:Mark, this seems an awful lot like an answer of "no", to my question "Is
there a contingency plan in the case that the incumbent chain following the
Bitcoin Core consensus rules comes under 51% attack?" - is this a correct
interpretation?
In fact, beyond a no, it seems like a "no, and I disagree with the idea of
creating one".
So if Bitcoin comes under successful 51%, the project, in your vision, has
simply failed?
*Ben Kloester*
On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at 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 at 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--) { # 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171011/338575fd/attachment.html>

2023-06-07 20:06:54

- reply

📅 Original date posted:2017-10-09
📝 Original message: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
<https://github.com/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 at 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 at 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--) { # 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/a592d3b6/attachment-0001.html>