Jacob Eliosoff [ARCHIVE]

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

Public Key

npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8d

Profile Code

nprofile1qqsdlsacv2gdjc4h9ys4xmm78dnvqd6zhpdtey2yg75s2p7vyllc5jcpzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxg7aza4s

Publishing to

relay.nostr.band

Author Public Key

npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8d

Show more details

Last Notes

2023-06-07 23:11:32

- reply

📅 Original date posted:2022-07-10
📝 Original message:> Credit where credit is due: after writing the bulk of this article I
found out
> that Monero developer [smooth_xmr](https://www.reddit.com/user/smooth_xmr/
)
> also observed that tail emission results in a stable coin supply
> [a few years ago](
https://www.reddit.com/r/Monero/comments/4z0azk/maam_28_monero_ask_anything_monday/d6sixyi/
).
> There's probably others too: it's a pretty obvious result.
Fwiw, Joe Lubin, April 2014: "The expected rate of annual loss and
destruction of ETH will balance the rate of issuance. Under this dynamic,
a quasi-steady state is reached and the amount of extant ETH no longer
grows."
https://blog.ethereum.org/2014/04/10/the-issuance-model-in-ethereum/
As you say, probably an observation various people have made. (Ethereum
has had some updates to its issuance model since 2014, in particular
EIP-1559 and the block reward reduction coming with PoS. But they've had a
fixed rather than halving block subsidy since launch so the question of
whether it implied infinite supply often came up.)
On Sat, Jul 9, 2022, 7:47 AM Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> New blog post:
>
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
>
> tl;dr: Due to lost coins, a tail emission/fixed reward actually results in
> a
> stable money supply. Not an (monetarily) inflationary supply.
>
> ...and for the purposes of reply/discussion, attached is the article
> itself in
> markdown format:
>
> ---
> layout: post
> title: "Surprisingly, Tail Emission Is Not Inflationary"
> date: 2022-07-09
> tags:
> - bitcoin
> - monero
> ---
>
> At present, all notable proof-of-work currencies reward miners with both a
> block
> reward, and transaction fees. With most currencies (including Bitcoin)
> phasing
> out block rewards over time. However in no currency have transaction fees
> consistently been more than 5% to 10% of the total mining
> reward[^fee-in-reward], with the exception of Ethereum, from June 2020 to
> Aug 2021.
> To date no proof-of-work currency has ever operated solely on transaction
> fees[^pow-tweet], and academic analysis has found that in this condition
> block
> generation is unstable.[^instability-without-block-reward] To paraphrase
> Andrew
> Poelstra, it's a scary phase change that no other coin has gone
> through.[^apoelstra-quote]
>
> [^pow-tweet]: [I asked on Twitter](
> https://twitter.com/peterktodd/status/1543231264597090304) and no-one
> replied with counter-examples.
>
> [^fee-in-reward]: [Average Fee Percentage in Total Block Reward](
> https://bitinfocharts.com/comparison/fee_to_reward-btc-eth-bch-ltc-doge-xmr-bsv-dash-zec.html#alltime
> )
>
> [^instability-without-block-reward]: [On the Instability of Bitcoin
> Without the Block Reward](
> https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf)
>
> [^apoelstra-quote]: [From a panel at TABConf 2021](
> https://twitter.com/peterktodd/status/1457066946898317316)
>
> Monero has chosen to implement what they call [tail
> emission](
> https://www.getmonero.org/resources/moneropedia/tail-emission.html):
> a fixed reward per block that continues indefinitely. Dogecoin also has a
> fixed
> reward, which they widely - and incorrectly - refer to as an "abundant"
> supply[^dogecoin-abundant].
>
> [^dogecoin-abundant]: Googling "dogecoin abundant" returns dozens of hits.
>
> This article will show that a fixed block reward does **not** lead to an
> abundant supply. In fact, due to the inevitability of lost coins, a fixed
> reward converges to a **stable** monetary supply that is neither
> inflationary
> nor deflationary, with the total supply proportional to rate of tail
> emission
> and probability of coin loss.
>
> Credit where credit is due: after writing the bulk of this article I found
> out
> that Monero developer [smooth_xmr](https://www.reddit.com/user/smooth_xmr/
> )
> also observed that tail emission results in a stable coin supply
> [a few years ago](
> https://www.reddit.com/r/Monero/comments/4z0azk/maam_28_monero_ask_anything_monday/d6sixyi/
> ).
> There's probably others too: it's a pretty obvious result.
>
>
> <div markdown="1" class="post-toc">
> # Contents
> {:.no_toc}
> 0. TOC
> {:toc}
> </div>
>
> ## Modeling the Fixed-Reward Monetary Supply
>
> Since the number of blocks is large, we can model the monetary supply as a
> continuous function $$N(t)$$, where $$t$$ is a given moment in time. If the
> block reward is fixed we can model the reward as a slope $$k$$ added to an
> initial supply $$N_0$$:
>
> $$
> N(t) = N_0 + kt
> $$
>
> Of course, this isn't realistic as coins are constantly being lost due to
> deaths, forgotten passphrases, boating accidents, etc. These losses are
> independent: I'm not any more or less likely to forget my passphrase
> because
> you recently lost your coins in a boating accident — an accident I probably
> don't even know happened. Since the number of individual coins (and their
> owners) is large — as with the number of blocks — we can model this loss as
> though it happens continuously.
>
> Since coins can only be lost once, the *rate* of coin loss at time $$t$$ is
> proportional to the total supply *at that moment* in time. So let's look
> at the
> *first derivative* of our fixed-reward coin supply:
>
> $$
> \frac{dN(t)}{dt} = k
> $$
>
> ...and subtract from it the lost coins, using $$\lambda$$ as our [coin loss
> constant](https://en.wikipedia.org/wiki/Exponential_decay):
>
> $$
> \frac{dN(t)}{dt} = k - \lambda N(t)
> $$
>
> That's a first-order differential equation, which can be easily solved with
> separation of variables to get:
>
> $$
> N(t) = \frac{k}{\lambda} - Ce^{-\lambda t}
> $$
>
> To remove the integration constant $$C$$, let's look at $$t = 0$$, where
> the
> coin supply is $$N_0$$:
>
> $$
> \begin{align}
> N_0 &= \frac{k}{\lambda} - Ce^{-\lambda 0} = \frac{k}{\lambda} - C \\
> C &= \frac{k}{\lambda} - N_0
> \end{align}
> $$
>
> Thus:
>
> $$
> \begin{align}
> N(t) &= \frac{k}{\lambda} - \left(\frac{k}{\lambda} - N_0
> \right)e^{-\lambda t} \\
> &= \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda}
> \right)e^{-\lambda t}
> \end{align}
> $$
>
>
> ## Long Term Coin Supply
>
> It's easy to see that in the long run, the second half of the coin supply
> equation goes to zero because $$\lim_{t \to \infty} e^{-\lambda t} = 0$$:
>
> $$
> \begin{align}
> \lim_{t \to \infty} N(t) &= \lim_{t \to \infty} \left[
> \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t}
> \right ] = \frac{k}{\lambda} \\
> N(\infty) &= \frac{k}{\lambda}
> \end{align}
> $$
>
> An intuitive explanation for this result is that in the long run, the
> initial
> supply $$N_0$$ doesn't matter, because approximately all of those coins
> will
> eventually be lost. Thus in the long run, the coin supply will converge
> towards
> $$\frac{k}{\lambda}$$, the point where coins are created just as fast as
> they
> are lost.
>
>
> ## Short Term Dynamics and Economic Considerations
>
> Of course, the intuitive explanation for why supply converges to
> $$\frac{k}{\lambda}$$, also tells us that supply must converge fairly
> slowly:
> if 1% of something is lost per year, after 100 years 37% of the initial
> supply
> remains. It's not clear what the rate of lost coins actually is in a
> mature,
> valuable, coin. But 1%/year is likely to be a good guess — quite possibly
> less.
>
> In the case of Monero, they've introduced tail emission at a point where it
> represents a 0.9% apparent monetary inflation rate[^p2pool-tail]. Since
> the number of
> previously lost coins, and the current rate of coin loss, is
> unknown[^unknowable] it's not possible to know exactly what the true
> monetary
> inflation rate is right now. But regardless, the rate will only converge
> towards zero going forward.
>
> [^unknowable]: Being a privacy coin with [shielded amounts](
> https://localmonero.co/blocks/richlist), it's not even possible to get an
> estimate of the total amount of XMR in active circulation.
>
> [^p2pool-tail]: P2Pool operates [a page with real-time date figures](
> https://p2pool.io/tail.html).
>
> If an existing coin decides to implement tail emission as a means to fund
> security, choosing an appropriate emission rate is simple: decide on the
> maximum amount of inflation you are willing to have in the worst case, and
> set
> the tail emission accordingly. In reality monetary inflation will be even
> lower
> on day zero due to lost coins, and in the long run, it will converge
> towards
> zero.
>
> The fact is, economic volatility dwarfs the effect of small amounts of
> inflation. Even a 0.5% inflation rate over 50 years only leads to a 22%
> drop.
> Meanwhile at the time of writing, Bitcoin has dropped 36% in the past
> year, and
> gained 993% over the past 5 years. While this discussion is a nice excuse
> to
> use some mildly interesting math, in the end it's totally pedantic.
>
> ## Could Bitcoin Add Tail Emission?
>
> ...and why could Monero?
>
> Adding tail emission to Bitcoin would be a hard fork: a incompatible rule
> change that existing Bitcoin nodes would reject as invalid. While Monero
> was
> able to get sufficiently broad consensus in the community to implement tail
> emission, it's unclear at best if it would ever be possible to achieve
> that for
> the much larger[^btc-vs-xmr-market-cap] Bitcoin. Additionally, Monero has a
> culture of frequent hard forks that simply does not exist in Bitcoin.
>
> [^btc-vs-xmr-market-cap]: [As of writing](
> https://web.archive.org/web/20220708143920/https://www.coingecko.com/),
> the apparent market cap of Bitcoin is $409 billion, almost 200x larger than
> Monero's $2.3 billion.
>
> Ultimately, as long as a substantial fraction of the Bitcoin community
> continue
> to run full nodes, the only way tail emission could ever be added to
> Bitcoin is
> by convincing that same community that it is a good idea.
>
>
> ## Footnotes
> _______________________________________________
> 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/20220710/1c603cdd/attachment-0001.html>

2023-06-07 18:16:48

- reply

📅 Original date posted:2019-03-12
📝 Original message:Also, if future disabling isn't the point of making a tx type like
OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite
support of these oddball features, what do we gain by making them hard to
use/mine?
I see questions like "Is it possible someone's existing tx relies on this?"
as overly black-and-white. We all agree it's possible: the question is how
likely, vs the harms of continued support - including not just security
risks but friction on other useful changes, safety/correctness analyses,
etc.
It is so easy to say stuff like this when one's own money isn't what is at
risk.
Stepping back for a second here: I dispute this framing. My money *is* at
risk, because the value of my bitcoins depends on adoption and feature
growth. And I've long viewed an absolutist, actual-known-user-indifferent
approach to backwards compatibility as the #1 impediment to Bitcoin's
adoption and growth.
Again, the point being not to throw caution to the wind, but that a case
like this where extensive research unearthed zero users, is taking caution
too far.
On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Note that even your carve-outs for OP_NOP is not sufficient here - if you
> were using nSequence to tag different pre-signed transactions into
> categories (roughly as you suggest people may want to do with extra sighash
> bits) then their transactions could very easily have become
> un-realistically-spendable. The whole point of soft forks is that we
> invalidate otherwise-unused bits of the protocol. This does not seem
> inconsistent with the proposal here.
>
> > On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor at blockstream.io>
> wrote:
> > Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
> _______________________________________________
> 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/20190312/a6624dfa/attachment.html>

2023-06-07 18:16:47

- reply

📅 Original date posted:2019-03-10
📝 Original message:>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
This principle was only ever a rule of thumb to protect users, not a
commandment from God. It shouldn't be violated lightly, but that's why
Matt did the legwork to show that the tradeoffs around OP_CODESEPARATOR
justify removing it.
Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years. Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do. Perhaps others don't want to risk
> blowing their pseudonymity. Perhaps they think that attempting to undo
> some of these non-standardness changes is futile. I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
Like Matt, I understand non-standardness to be specifically for making a
transaction type more difficult to set the stage for a future disabling.
If anyone is actually harmed by this change, let them at least speak up
pseudonymously as others have before. Backwards compatibility shouldn't
mean letting imaginary implausible cases veto net-beneficial changes.
On Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Matt,
>
> On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> Replies inline.
>>
>> On 3/8/19 3:57 PM, Russell O'Connor wrote:
>> > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists at mattcorallo.com
>> > <mailto:lf-lists at mattcorallo.com>> wrote:
>> > It's very easy to construct a practical script using OP_CODESEPARATOR.
>> >
>> > IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
>> > CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
>> >
>> > Now when someone hands Alice, the CFO of XYZ corp., some transaction,
>> > she has the option of either signing it unilaterally herself, or
>> > creating a partial signature such that the transaction additionally
>> > needs Bob, the CEOs signature as well, and Alice's choice is committed
>> > to the blockchain for auditing purposes later.
>> >
>> > Now, there are many things you might object about this scheme, but my
>> > point is that (A) regardless of what you think about this scheme, it,
>> or
>> > similar schemes, may have been devised by users, and (B) users may have
>> > already committed funds to such schemes, and due to P2SH you cannot
>> know
>> > that this is not the case.
>>
>> The common way to set that up is to have a separate key, but, ok, fair
>> enough. That said, the argument that "it may be hidden by P2SH!" isn't
>> sufficient here. It has to *both* be hidden by P2SH and have never been
>> spent from (either on mainnet or testnet) or be lock-timed a year in the
>> future. I'm seriously skeptical that someone is using a highly esoteric
>> scheme and has just been pouring money into it without ever having
>> tested it or having withdrawn any money from it whatsoever. This is just
>> a weird argument.
>>
>
> No one is required to test their Scripts on a public testnet; they can use
> regtest. Because these transactions are non-standard on mainnet, it could
> take years to arrange for these funds to be recovered by having their
> transactions mined directly, or take years to become valuable enough to be
> worth bothering having them directly mined. As I have noted elsewhere, you
> cannot first make transactions non-standard and then use the fact that you
> don't see them being used on mainnet to justify a soft-fork.
>
> My argument isn't weird; it is principled. You are skeptical that any
> uses of OP_CODESEPARATOR have P2SH commitments. I am also skeptical, and
> so is everyone reading this mailing list. But none of us know this with
> certainty, and it is /wrong/ for any of us to gamble with other people's
> money that our assumptions are true.
>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that
> invalidated transactions that send secured inputs to secured outputs
> (excluding uses of OP_NOP1-OP_NOP10).
>
> The fact that Bitcoin has stuck to this principle gives me and everyone
> else confidence in the protocol; that anyone can secure their funds by
> whatever scheme they dream up, and deploy it without needing permission or
> anyone else to vet their Scripts. So long as they are not impairing the
> Bitcoin protocol itself, the most that Bitcoin Core will do is stop
> relaying their transactions by default.
>
> Undermining this principle means undermining what provides Bitcoin's value
> in the first place.
>
> The problem in this particular case is that there exist valid secure
> transactions that make use OP_CODESEPARATOR such that these transactions
> themselves impair the Bitcoin protocol (through excessive validation costs)
> in a way that, AFAIU, is fundamental to the nature of such transactions (in
> particular, it isn't just due to an implementation detail of Bitcoin
> Core). Thus to fix this vulnerability we must necessarily violate the
> principle of not invalidating, secure transactions. However, this fact
> isn't license to freely invalidate any transactions we want. We ought to
> strive to minimize the scope of violation of this principle. Alice and Bob
> from XYZ. corp should be able to keep their benign transaction illustrated
> above, and we only eliminate those transactions that actually impair the
> Bitcoin protocol.
>
> This is the perfect opportunity to show the world that Bitcoin Core simply
> doesn't take chances when it comes to other people money.
>
> > Please don't strawman my position. I am not suggesting we don't fix a
>> > vulnerability in Bitcoin. I am suggesting we find another way. One
>> > that limits the of risk destroying other people's money.
>> >
>> > Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR
>> > is, it cannot be worse than instead including another input that spends
>> > another identically sized UTXO. So how about we soft-fork in a rule
>> > that says that an input's weight is increased by an amount equal to the
>> > number of OP_CODESEPARATORs executed times the sum of weight of the
>> UTXO
>> > being spent and 40 bytes, the weight of a stripped input. The risk of
>> > destroying other people's money is limited and AFAIU it would
>> completely
>> > address the vulnerabilities caused by OP_CODESEPARATOR.
>>
>> You're already arguing that someone has such an esoteric use of script,
>> suggesting they aren't *also* creating pre-signed, long-locktimed
>> transactions with many inputs isn't much of a further stretch
>> (especially since this may result in the fee being non-standardly low if
>> you artificially increase its weight).
>>
>
> There is no consensus rule about minimum fees, and CPFP could add the more
> fees. But yes, I am saying that Alice and Bob could be building on their
> transaction illustrated above, but not creating a many input tx that
> wouldn't fit into a block with my proposed added weight, because if their
> transaction won't fit into a block with the added weight then it was a
> malicious transaction to begin with.
>
> Do you not recognize the material difference between a soft-fork that
> doubles the cost of a transaction like Alice and Bob's versus making their
> transaction entirely illegal?
>
>
>> Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
>> of complexity and reduces the simple analysis that fees (almost) have
>> today vs just removing it allows us to also remove a ton of code.
>
>
> Further note that if you don't remove it getting the efficiency wins
>> right is even harder because instead of being able to cache sighashes
>> you now have to (at a minimum) wipe the cache between each
>> OP_CODESEPARATOR call, which results in a ton of additional
>> implementation complexity.
>>
>
> How can this be "additional" complexity when this is how the protocol
> works today? All you have to do is not change the semantics of
> OP_CODESEPARATOR. It is literally no work.
> Regarding the efficiency wins, let me repeat myself: The performance costs
> of wiping the cached sighashs is not worse than what the performance costs
> would be if the transaction had an additional input spending an equally
> sized UTXO.
>
>
>> > > I suggest an alternative whereby the execution of
>> OP_CODESEPARATOR
>> > > increases the transactions weight suitably as to temper the
>> > > vulnerability caused by it. Alternatively there could be some
>> > sort of
>> > > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
>> > allowed to be
>> > > executed per script, but that would require an argument as to why
>> > > exceeding that limit isn't reasonable.
>> >
>> > You could equally argue, however, that any such limit could render
>> some
>> > moderately-large transaction unspendable, so I'm somewhat skeptical
>> of
>> > this argument. Note that OP_CODESEPARATOR is non-standard, so
>> getting
>> > them mined is rather difficult in any case.
>> >
>> >
>> > I already know of people who's funds are tied up due to in other
>> changes
>> > to Bitcoin Core's default relay policy. Non-standardness is not an
>> > excuse to take other people's tied up funds and destroy them
>> permanently.
>>
>> Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years. Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do. Perhaps others don't want to risk
> blowing their pseudonymity. Perhaps they think that attempting to undo
> some of these non-standardness changes is futile. I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
> Regarding OP_CODESEAPRATOR specifically, disabling the rely of such
> transactions partially mitigates the vulnerability. Once the vulnerability
> is properly patched, for example by suitably increasing the weight of the
> operation or opcode, we could drop the prohibition on relaying such
> transactions. Non-standardness is not necessarily a path to a new
> consensus rule. We have several non-standardness rules in place that are
> never intended to become new consensus rules. Sometimes non-standardness
> is a temporary mitigation.
>
> _______________________________________________
> 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/20190309/900b7770/attachment-0001.html>

2023-06-07 18:07:38

- reply

📅 Original date posted:2017-11-15
📝 Original message:>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
OK, but then it seems to me you have a dilemma for, eg, your LN commitment
tx. You either give it the specific nForkId of the fork it's created on -
making it invalid on *all* other forks (eg, any future "non-contentious
upgrade" HF that replaces that fork). Or you give it nForkId 0 - which has
the "BCH tx valid on Segwit2x (& vice versa)" flaw.
It may make sense to revise your proposal to incorporate Luke's
OP_CHECKBLOCKATHEIGHT
<https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki>, and make
the fork ID a (block height, hash) pair rather than just a number. But I
still think the idea of fork-specific addresses is a keeper!
On Tue, Nov 14, 2017 at 8:49 AM, Mats Jerratsch <mats at blockchain.com> wrote:
>
> But I like the 'old' idea of putting the hash of a block that MUST be on
> the chain that this txn can eventually be added to. If the hash is not a
> valid block on the chain, the txn can't be added.
>
> It means you can choose exactly which forks you want to allow your txn on,
> pre-fork for both, post-fork for only one, and gets round the issue of who
> gets to decide the nForkid value.. since you don't need one. Also, all the
> old outputs work fine, and LN not an issue.
>
> I'm missing why this scheme would be better ?
>
>
> I do agree that solutions like `SIGHASH_BLOCKCOMMIT` are superior in the
> sense that they are very difficult to circumvent. However, a fork could
> also follow the original chain in SPV mode and allow transactions protected
> with these mechanism. Since it's fundamentally impossible to disallow
> transactions in future projects, the goal shouldn't be to make this overly
> complicated.
>
> Furthermore, this schema is not just adding replay protection. It makes
> transacting safer overall (due to a dedicated address format per fork) and
> allows light clients to differentiate between multiple forks. In the past
> three months, at least $600k has been lost by users sending BCH to a BTC
> address [1].
>
> Thanks for the clarification. How would a tx specify a constraint like
>> "nForkId>=1"? I was thinking of it just as a number set on the tx.
>>
>
> Whether the transaction is replay protected or not is specified by setting
> a bit in the `SigHashId`. If this bit is set, then the signature *preimage*
> MUST have `nForkId` appended. `nForkId` is not part of the final
> transaction, someone who wants to verify the transaction must know which
> `nForkId` it was created with.
>
> If the bit isn't set, it means `nForkId=0`, which allows other forks to
> validate the signature.
>
> Also note that since forks form a partial order, but IDs (numbers) form a
>> total order, ">=" will miss some cases. Eg, suppose BCH had forked with
>> nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
>> then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would
>> be valid on Segwit2x. This is more of a fundamental problem than a bug -
>> to avoid it you'd have to get into stuff like making each fork reference
>> its parent-fork's first block or something, someone has written about
>> this...
>>
>
> Sorry, I was careless with the use of `>=` there. You are correct, forks
> form a tree. For this proposal, every leaf must be assigned a unique
> `nForkId`. The relationship between `nForkId` is irrelevant (e.g. which
> number is bigger), as long as they are unique. Transactions are only valid
> IFF `nForkId` matches exactly the `nForkId` of the software validating it.
> As described above, the transaction doesn't even contain `nForkId`, and the
> node surely is not starting to guess which one it could be.
>
> [1]
> https://twitter.com/khannib/status/930223617744437253
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171115/83057847/attachment.html>

2023-06-07 18:07:37

- reply

📅 Original date posted:2017-11-13
📝 Original message:>
> This is actually incorrect. There are two transactions involved in LN. The
> funding transaction, which opens a payment channel, and a commitment
> transaction, which closes the channel when broadcasted to the network (the
> cooperative closing transaction can be considered a commitment transaction
> in a loose sense).
>
> Now you want to protect the funding transaction, as otherwise you would be
> subject to a replay-attack on all *past* forks. So you will set
> `nForkId>=1` for the funding transaction, making this payment channel
> non-existent on any *past* forks. However, if during the lifetime of the
> payment channel another fork happens, the payment channel exists for both
> tokens. So for the commitment transaction, you will have `nForkId=0`,
> making it valid on both of these chains. While this `nForkId` is valid on
> all chains, the parent transaction it tries to spend (the funding
> transaction) does only exist on two chains, the original one you created
> the channel for and the one that forked away.
>
Thanks for the clarification. How would a tx specify a constraint like
"nForkId>=1"? I was thinking of it just as a number set on the tx.
Also note that since forks form a partial order, but IDs (numbers) form a
total order, ">=" will miss some cases. Eg, suppose BCH had forked with
nForkId 2, and then you set up a LN funding tx on BCH with nForkId>=2, and
then Segwit2x forked (from BTC!) with nForkId 3. The BCH funding tx would
be valid on Segwit2x. This is more of a fundamental problem than a bug -
to avoid it you'd have to get into stuff like making each fork reference
its parent-fork's first block or something, someone has written about
this...
On Mon, Nov 13, 2017 at 5:03 AM, Mats Jerratsch <mats at blockchain.com> wrote:
>
> OK, so nForkId 0 is exactly the "valid on all chains" specifier I was
> asking about, cool. And your LN example (and nLockTime txs in general)
> illustrate why it's preferable to implement a generic replay protection
> scheme like yours *in advance*, rather than before each fork: all ad hoc
> RP schemes I know of break old txs on one of the chains, even when that's
> not desirable - ie, they offer no wildcard like nForkId 0.
>
>
> Exactly!
>
> One comment on your LN example: users would have to take note that nForkId
> 0 txs would be valid not only on future forks, but on *past* forks too.
> Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN
> txs now with nForkId 0 would have to be aware that those txs would be valid
> for BCH too. Of course the user could avoid this by funding from a
> BTC-only address, but it is a potential minor pitfall of nForkId 0. (Which
> I don't see any clean way around.)
>
>
> This is actually incorrect. There are two transactions involved in LN. The
> funding transaction, which opens a payment channel, and a commitment
> transaction, which closes the channel when broadcasted to the network (the
> cooperative closing transaction can be considered a commitment transaction
> in a loose sense).
>
> Now you want to protect the funding transaction, as otherwise you would be
> subject to a replay-attack on all *past* forks. So you will set
> `nForkId>=1` for the funding transaction, making this payment channel
> non-existent on any *past* forks. However, if during the lifetime of the
> payment channel another fork happens, the payment channel exists for both
> tokens. So for the commitment transaction, you will have `nForkId=0`,
> making it valid on both of these chains. While this `nForkId` is valid on
> all chains, the parent transaction it tries to spend (the funding
> transaction) does only exist on two chains, the original one you created
> the channel for and the one that forked away.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171113/ae5bea73/attachment-0001.html>

2023-06-07 18:07:36

- reply

📅 Original date posted:2017-11-11
📝 Original message:OK, so nForkId 0 is exactly the "valid on all chains" specifier I was
asking about, cool. And your LN example (and nLockTime txs in general)
illustrate why it's preferable to implement a generic replay protection
scheme like yours *in advance*, rather than before each fork: all ad hoc RP
schemes I know of break old txs on one of the chains, even when that's not
desirable - ie, they offer no wildcard like nForkId 0.
One comment on your LN example: users would have to take note that nForkId
0 txs would be valid not only on future forks, but on *past* forks too.
Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN
txs now with nForkId 0 would have to be aware that those txs would be valid
for BCH too. Of course the user could avoid this by funding from a
BTC-only address, but it is a potential minor pitfall of nForkId 0. (Which
I don't see any clean way around.)
On Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch <mats at blockchain.com> wrote:
> I guess I wasn't clear on the wildcard, `nForkId=0`
>
> This proposal puts Bitcoin at `nForkId=1`, with the purpose of having
> `nForkId=0` valid on *all* future forks. This means you can create a
> `nLockTime` transaction, delete the private key and still be assured to not
> lose potential future tokens.
>
> In theory `nForkId=0` could be used for an address too, the sending wallet
> should display a warning message about unknown side effects though. This
> address would be future-safe, and you can put it into a safe-deposit box
> (even though I see little reason to back up an _address_. You would always
> back up a _private key_, which translates into funds on any fork.)
>
> Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice
> and Bob open a payment channel. One week later, project X decides to fork
> the network into a new token, implementing a custom way of providing strong
> two-way replay protection. The protocol Alice and Bob use for the payment
> channel has not implemented this new form of replay protection. Alice and
> Bob now have to make a choice:
>
> (1) Ignore this new token. This comes with an evaluation of how much this
> new token could be worth in the future. They will continue normal channel
> operation, knowing that their funds on the other branch will be locked up
> until eternity. When they close their payment channel, the closing
> transaction will get rejected from the other network, because it's not
> following the format for replay protected transactions.
>
> (2) Close the payment channel before the fork. The transaction, which
> closes the payment channel has to be mined before the fork, potentially
> paying a higher-than-normal fee.
>
> With this proposal implemented, there are two additional choices
>
> (3) Create the commitment transactions with `nForkId=0`. This ensures that
> when the channel gets closed, funds on other chains are released
> accordingly. This also means that after the fork, payments on the channel
> move both, the original token and the new token. Potentially, Alice and Bob
> want to wait before further transacting on the channel, to see if the token
> has substantial value. If it has, they can *then* close the channel and
> open a new channel again. (Note: The funding transaction can use a specific
> `nForkId`, preventing you from locking up multiple coins when funding the
> channel, but you can choose to settle with `nForkId=0` to not lock up
> future coins)
>
> (4) Make the protocol aware of different `nForkId`. After the fork, the
> participants can chose to *only* close the payment channel on the new
> token, making the payment channel Bitcoin-only again. This is the preferred
> option, as it means no disruption to the original network.
>
> > I like the idea of specifying the fork in bech32 [0]. On the other hand,
> the standard already has a human readable part. Perhaps the human readable
> part can be used as the fork id?
>
> I was considering this too. On the other hand, it's only _human readable_
> because thy bytes used currently encode 'bc'. For future forks, this would
> just be two random letters than, but potentially acceptable.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171111/9fb7d5ba/attachment-0001.html>

2023-06-07 18:07:35

- reply

📅 Original date posted:2017-11-09
📝 Original message:OK, I see. On the whole this is the best replay protection solution I've
seen. In particular, I hope developers of Bech32 and other new address
formats will take a close look at incorporating a fork ID this way.
As I understand you, a private key in cold storage would (of course) remain
valid across HFs, but an *address* would be valid only for the nForkId it
was generated for. There may be cold-storage-type cases where it's
important for an address to be valid across all chains, ie, to
intentionally allow replay? But I guess this could just be a special
nForkId value, say -1?
On Nov 8, 2017 9:45 AM, "Mats Jerratsch" <mats at blockchain.com> wrote:
> Hey Jacob!
>
> > Take the specific and common case of non-upgraded wallet software.
> Suppose a HF happens, and becomes the network used by 90% of users. Will
> old wallets still default to the old nForkId (10% legacy chain)? If so,
> I'd expect a lot of accidental mis-sends on that chain.
>
> With this proposal implemented, a 'mis-send' is fundamentally impossible.
> The address contains the identifier of the token that should be sent.
>
> If anything, it's possible to 'mis-receive'.
> That is, the receiving wallet was not aware of a newer chain, and the
> receiver actually wanted to receive the newer token, but instead his wallet
> created an address for the old token. It is the responsibility of the
> receiver to write a correct invoice. This is the case everywhere else in
> the world too, so this seems like a reasonable trade-off.
>
> I would even argue that this should hold in a legal case, where the
> receiver cannot claim that he was expecting a payment in another token
> (contrary to how it is today, like when users send BTC to a BCH address,
> losing their funds with potentially no legal right for reimbursement). If I
> sent someone an invoice over 100€, I cannot later proclaim that I actually
> expected $100.
>
> With this proposal, wallets are finally able to distinguish between
> different tokens. With this ability, I expect to see different
> implementations, some wallets which advertise staying conservative,
> following a strict ruleset, and other wallets being more experimental,
> following hashing rate or other metrics.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171109/b20d9108/attachment.html>

2023-06-07 18:07:34

- reply

📅 Original date posted:2017-11-06
📝 Original message:Thanks Mats, this proposal makes sense to me (especially the idea of
fork-specific addresses). It prevents replay across forks, and makes it
easy for client software, and thus potentially users, to specify which fork
a tx is for. But, like other (rougher) past proposals I've seen, it does
little to prevent users from accidentally sending on the wrong fork.
Take the specific and common case of non-upgraded wallet software. Suppose
a HF happens, and becomes the network used by 90% of users. Will old
wallets still default to the old nForkId (10% legacy chain)? If so, I'd
expect a lot of accidental mis-sends on that chain.
This is just a gap in your proposal, not a flaw, but it's worth thinking
about less hazard-prone ways wallets could default nForkId. Perhaps they
could listen to all forks, and default to the one whose last (recent) block
had the highest difficulty? Or just check those blocks to see if multiple
forks are (nontrivially) active, and if so warn the user and force them to
confirm? Something like that.
On Nov 6, 2017 7:05 AM, "Mats Jerratsch via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Presented is a generalised way of providing replay protection for future
hard forks. On top of replay protection, this schema also allows for
fork-distinct addresses and potentially a way to opt-out of replay
protection of any fork, where deemed necessary (can be beneficial for some
L2 applications).
## Rationale
Currently when a hard fork happens, there is ad-hoc replay protection built
within days with little review at best, or no replay protection at all.
Often this is either resource problem, where not enough time and developers
are available to sufficiently address replay protection, or the idea that
not breaking compatibility is favourable. Furthermore, this is potentially
a recurring problem with no generally accepted solution yet. Services that
want to deal in multiple forks are expected to closely follow all projects.
Since there is no standard, the solutions differ for each project,
requiring custom code for every fork. By integrating replay protection into
the protocol, we advocate the notion of non-hostile forks.
Users are protected against accidentally sending coins on the wrong chain
through the introduction of a fork-specific incompatible address space. The
coin/token type is encoded in the address itself, removing some of the
importance around the question _What is Bitcoin?_. By giving someone an
address, it is explicitly stated _I will only honour a payment of token X_,
enforcing the idea of validating the payment under the rules chosen by the
payee.
## Iterative Forks
In this schema, any hard fork is given an incremented id, `nForkId`.
`nForkId` starts at `1`, with `0` being reserved as a wildcard. When
project X decides to make an incompatible change to the protocol, it will
get assigned a new unique `nForkId` for this fork. A similar approach like
for BIP43 can be taken here. Potentially `nForkId` can be reused if a
project has not gained any amount of traction.
When preparing the transaction for signing or validation, `nForkId` is
appended to the final template as a 4B integer (similar to [1]). Amending
BIP143, this would result in
```
Double SHA256 of the serialization of:
1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)
5. scriptCode of the input (serialized as scripts inside CTxOuts)
6. value of the output spent by this input (8-byte little endian)
7. nSequence of the input (4-byte little endian)
8. hashOutputs (32-byte hash)
9. nLocktime of the transaction (4-byte little endian)
10. sighash type of the signature (4-byte little endian)
11. nForkId (4-byte little endian)
```
For `nForkId=0` this step is ommitted. This will immediately invalidate
signatures for any other branch of the blockchain than this specific fork.
To distinguish between `nForkId=0` and `nForkId` hardcoded into the
software, another bit has to be set in the 1B SigHashId present at the end
of signatures.
To make this approach more generic, payment addresses will contain the fork
id, depending on which tokens a payee expects payments in. This would
require a change on bech32 addresses, maybe to use a similar format used in
lightning-rfc [2]. A wallet will parse the address, it will extract
`nForkId`, and it displays which token the user is about to spend. When
signing the transaction, it will use `nForkId`, such that the transaction
is only valid for this specific token. This can be generalised in software
to the point where replay protection *and* a new address space can be
introduced for forks without breaking existing clients.
For light clients, this can be extended by enforcing the coinbase/block
header to contain the `nForkId` of the block. Then the client can
distinguish between different chains and tokens it received on each.
Alternatively, a new P2P message type for sending transactions could be
introduced, where prevOut and `nForkId` is transmitted, such that the lite
client can check for himself, which token he received.
Allowing signatures with `nForkId=1` can be achieved with a soft fork by
incrementing the script version of SegWit, making this a fully backwards
compatible change.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
2017-February/013542.html
[2]
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-
encoding.md
_______________________________________________
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/20171106/91e3799f/attachment.html>

2023-06-07 18:07:32

- reply

📅 Original date posted:2017-11-04
📝 Original message:I'm no BCH fan, but I agree with Scott that changes to the DAA may be of
more than purely theoretical interest for BTC. Anyway just for those
interested, below is an algo I've been playing with that adjusts difficulty
every block, based only on the previous block's time and difficulty. I
tested it a bit and it seems to adapt to hashrate swings pretty well.
weight_n = 1 - e^-(blocktime_n / 1 hr) # 1 hr = exp moving avg window -
too short?
adj_n = (10 min / blocktime_n) - 1
difficulty_(n+1) = difficulty_n * (1 + weight_n * adj_n)
It could also be tweaked to make the *historical* avg block time ~exactly
10 minutes, ie, to target > 10 min if past blocks were < 10 min. This
would, eg, make mapping future block numbers to calendar times much more
exact.
On Nov 3, 2017 7:24 AM, "Scott Roberts via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The current DA is only sufficient if the coin has the highest
> hashpower. It's also just really slow. If miners somehow stick with
> SegWit2x despite the higher rewards in defecting back to bitcoin, then
> bitcoin will have long block delays. High transaction fees will
> probably help them defect back to us. But if SegWit2x manages to be
> more comparable in price than BCH (despite the futures), hashpower
> could very well oscillate back and forth between the two coins,
> causing delays in both of them. The first one to hard fork to fix the
> difficulty problem will have a large advantage, as evidenced by what
> happens in alts. In any event someday BTC may not be the biggest kid
> on the block and will need a difficulty algorithm that alts would find
> acceptable. Few alts use anything like BTC's because they are not able
> to survive the resulting long delays. I am recommending BTC
> developers watch what happens as BCH goes live with a much better
> algorithm, in case BTC needs to hard fork for the same reason and
> needs a similar fix. Ignore the trolls.
>
> On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe <cryptaxe at gmail.com> wrote:
> > Is there an issue with the current difficulty adjustment algorithm? It's
> > worked very well as far as I can tell. Introducing a new one seems pretty
> > risky, what would the benefit be?
> >
> > On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev"
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Bitcoin cash will hard fork on Nov 13 to implement a new difficulty
> >> algorithm. Bitcoin itself might need to hard fork to employ a similar
> >> algorithm. It's about as good as they come because it followed the
> >> "simplest is best" route. Their averaging window is probably
> >> significantly too long (N=144). It's:
> >>
> >> next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)
> >>
> >> They correctly did not use max(timestamp) - min(timestamp) in the
> >> denominator like others do.
> >>
> >> They've written the code and they're about to use it live, so Bitcoin
> >> will have a clear, simple, and tested path if it suddenly needs to
> >> hard fork due to having 20x delays for the next 2000 blocks (taking it
> >> a year to get unstuck).
> >>
> >> Details on it and the decision process:
> >> https://www.bitcoinabc.org/november
> >>
> >> It uses a nice median of 3 for the beginning and end of the window to
> >> help alleviate bad timestamp problems. It's nice, helps a little, but
> >> will also slow its response by 1 block. They also have 2x and 1/2
> >> limits on the adjustment per block, which is a lot more than they will
> >> ever need.
> >>
> >> I recommend bitcoin consider using it and making it N=50 instead of 144.
> >>
> >> I have seen that any attempts to modify the above with things like a
> >> low pass filter, starting the window at MTP, or preventing negative
> >> timestamps will only reduce its effectiveness. Bitcoin's +12 and -6
> >> limits on the timestamps are sufficient and well chosen, although
> >> something a bit smaller than the +12 might have been better.
> >>
> >> One of the contenders to the above is new and actually better, devised
> >> by Degnr8 and they call it D622 or wt-144.It's a little better than
> >> they realize. It's the only real improvement in difficulty algorithms
> >> since the rolling average. It gives a linearly higher weight to the
> >> more recent timestamps. Otherwise it is the same. Others have probably
> >> come across it, but there is too much noise in difficulty algorithms
> >> to find the good ones.
> >>
> >> # Degnr8's D622 difficulty algorithm
> >> # T=TargetTime, S=Solvetime
> >> # modified by zawy
> >> for i = 1 to N (from oldest to most recent block)
> >> t += T[i] / D[i] * i
> >> j += i
> >> next i
> >> next_D = j / t * T
> >>
> >> I believe any modification to the above strict mathematical weighted
> >> average will reduce it's effectiveness. It does not oscillate anymore
> >> than regular algos and rises faster and drops faster, when needed.
> >> _______________________________________________
> >> 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/20171103/2e7123e2/attachment.html>

2023-06-07 18:04:24

- reply

📅 Original date posted:2017-07-12
📝 Original message:Just a quick note in favor of an updated roadmap (some may object to that
label, but I think it's fine). When you and your friends are planning your
weekly movie outing, it's very helpful to have someone who knows the group,
knows what films are playing, checks people's preferences, mails around
proposals, updates with corrections, keeps a list of choices for future
weeks, etc. (Certainly not the same as imposing an agenda, except when the
coordinator gets pushy.)
Core veterans like those on this thread are well placed to compile (not
decree) such a document - basically an informed view of what looks likely
to get rough consensus, and in what order. *Of course* some will dispute
the priorities etc, but it's my experience that if everyone virtuously
refrains from this kind of coordination effort, often the weekend rolls by
without a film.
Agreed that specific deadlines often create more problems than they solve,
but even without dates, clarifying priorities (eg, segwit before HF) is
still useful.
All this is aside from the fact that I have many criticisms of the "movies
chosen" so far and the criteria used to choose them - another thread
(basically, I support an interpretation of "consensus" that takes more note
of non-dev constituents). The consensus-marshaling effort is still
important, and appreciated.
On Tue, Jul 11, 2017 at 8:21 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> And please try to avoid going off-topic -- this is supposed to be about
> the idea of a new roadmap.
>
> Paul
>
> _______________________________________________
> 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/20170712/516ee858/attachment.html>

2023-06-07 18:03:30

- reply

📅 Original date posted:2017-06-21
📝 Original message:Well, this Saturday's "Chinese roundtable" statement from a bunch of
miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
coinbase as support for "the New York consensus SegWit2x program btc1 (
https://github.com/btc1)", whose code includes the (accelerated 336-block)
BIP 91 change. So, other facts or interpretations could come to light, but
until they do we should probably assume that's what the "NYA" (which just
broke 80% over the last 24h) means.
On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> 80% have set "NYA" in their coinbase string. We have no idea what that
> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
> the time of the New York agreement, and differs from the actual text
> of the NYA in substantive ways. The "Segwit2MB" that existed at the
> time of the NYA, and which was explicitly referenced by the text is
> the proposal by Sergio Demian Lerner that was made to this mailing
> list on 31 March. The text of the NYA grants no authority for
> upgrading this proposal while remaining compliant with the agreement.
> This is without even considering the fact that in the days after the
> NYA there was disagreement among those who signed it as to what it
> meant.
>
> I feel it is a very dangerous and unwarranted assumption people are
> making that what we are seeing now is either 80% support for BIP-91 or
> for the code in the btc1 repo.
>
> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik at q32.com> wrote:
> > # Jacob Eliosoff:
> >
> >> will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
> split.
> >
> > Correct. There are 2 short activation periods in BIP91 either of which
> > would avoid a split.
> >
> > # Gregory Maxwell:
> >
> >> unclear to me _exactly_ what it would need to implement to be
> consistent.
> >
> > This is the relevant pull req to core:
> >
> > https://github.com/bitcoin/bitcoin/pull/10444
> >
> > Seems OK. It's technically running now on testnet5. I think it (or a
> > -bip148 option) should be merged as soon as feasible.
> >
> >> previously debunked "XT" and "Classic" hysteria.
> >
> > apples vs oranges, imo. segwit is not a contentious feature. the
> > "bundling" in segwit2x is, but that's not the issue here. the issue is
> we
> > are indirectly requiring miners that strongly support segwit to install
> > consensus protocol changes outside of bitcoin's standard reference.
> 80% of
> > them have signaled they will do so. these are uncharted waters.
> >
> >
> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> I could be wrong, but the latest BIP91 implementation (also included in
> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This
> has
> >> been updated at
> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So
> if 80%
> >> of hashpower is actually running that code and signaling on bit 4 by
> July 25
> >> or so, then those 80+% will start orphaning non-bit-1 blocks before Aug
> 1,
> >> and we avoid a split.
> >>
> >> There may still be a few non-bit-1 blocks that get orphaned after Aug 1,
> >> because they're mined by old BIP141 nodes. But it seems like very few
> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
> >>
> >> Make sense?
> >>
> >>
> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark at friedenbach.org
> >
> >> wrote:
> >>>
> >>> Why do you say activation by August 1st is likely? That would require
> an
> >>> entire difficulty adjustment period with >=95% bit1 signaling. That
> seems a
> >>> tall order to organize in the scant few weeks remaining.
> >>>
> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> If segwit is activated before Aug 1, as now seems likely, there will be
> >>> no split that day. But if activation is via Segwit2x (also likely),
> and at
> >>> least some nodes do & some don't follow through with the HF 3mo later
> >>> (again, likely), agreed w/ Greg that *then* we'll see a split -
> probably in
> >>> Sep/Oct. How those two chains will match up and how the split will
> play out
> >>> is anyone's guess...
> >>>
> >>>
> >>>
> >>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev"
> >>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> > Ironically, it looks like most of the segwit2x signaling miners are
> >>> > faking it (because they're not signaling segwit which it requires).
> >>> > It'll be unfortunate if some aren't faking it and start orphaning
> >>> > their own blocks because they are failing to signal segwit.
> >>>
> >>> Well, they're doing some kind of "pre-signaling" in the coinbase at the
> >>> moment, because the segwit2x project is still in alpha-phase according
> to
> >>> the timeline. They're just showing commitment.
> >>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
> >>> actually running a segwit2x node when the time comes.
> >>>
> >>>
> >>> > As far as prevent a chain split goes, all those things
> >>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so
> I
> >>> > don't think that holds.
> >>>
> >>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
> >>> BIP148) node, because they wouldn't have the new consensus rule of
> requiring
> >>> all blocks to signal for segwit.
> >>> I don't believe there would be any long lasting chainsplit though
> >>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks
> if we
> >>> get unlucky.
> >>>
> >>> Hampus
> >>>
> >>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev
> >>> <bitcoin-dev at lists.linuxfoundation.org>:
> >>>>
> >>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>> > Because a large percentage of miners are indifferent, right now
> miners
> >>>> > have
> >>>> > to choose between BIP148 and Segwit2x if they want to activate
> Segwit.
> >>>>
> >>>> Miners can simply continuing signaling segwit, which will leave them
> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
> >>>> what "segwit2x" is since they keep changing the actual definition and
> >>>> do not have a specification; but last I saw the near-term behavior the
> >>>> same as BIP91 but with a radically reduced activation window, so the
> >>>> story would be the same there in the near term).
> >>>>
> >>>> Ironically, it looks like most of the segwit2x signaling miners are
> >>>> faking it (because they're not signaling segwit which it requires).
> >>>> It'll be unfortunate if some aren't faking it and start orphaning
> >>>> their own blocks because they are failing to signal segwit.
> >>>>
> >>>> I don't think the rejection of segwit2x from Bitcoin's developers
> >>>> could be any more resolute than what we've already seen:
> >>>> https://en.bitcoin.it/wiki/Segwit_support
> >>>>
> >>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
> >>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>> > I think it is very naïve to assume that any shift would be
> temporary.
> >>>> > We have a hard enough time getting miners to proactively upgrade to
> >>>> > recent versions of the reference bitcoin daemon. If miners interpret
> >>>> > the situation as being forced to run non-reference software in order
> >>>> > to prevent a chain split because a lack of support from Bitcoin
> Core,
> >>>> > that could be a one-way street.
> >>>>
> >>>> I think this is somewhat naive and sounds a lot like the repeat of the
> >>>> previously debunked "XT" and "Classic" hysteria.
> >>>>
> >>>> There is a reason that segwit2x is pretty much unanimously rejected by
> >>>> the technical community. And just like with XT/Classic/Unlimited
> >>>> you'll continue to see a strong correlation with people who are
> >>>> unwilling and unable to keep updating the software at an acceptable
> >>>> level of quality-- esp. because the very founding on their fork is
> >>>> predicated on discarding those properties.
> >>>>
> >>>> If miners want to go off and create an altcoin-- welp, thats something
> >>>> they can always do, and nothing about that will force anyone to go
> >>>> along with it.
> >>>>
> >>>> As far as prevent a chain split goes, all those things
> >>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> >>>> don't think that holds.
> >>>> _______________________________________________
> >>>> 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/20170621/9b66620b/attachment-0001.html>

2023-06-07 18:03:28

- reply

📅 Original date posted:2017-06-20
📝 Original message:I could be wrong, but the latest BIP91 implementation (also included in
Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This has
been updated at
https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.) So if 80%
of hashpower is actually running that code and signaling on bit 4 by July
25 or so, then those 80+% will start orphaning non-bit-1 blocks before Aug
1, and we avoid a split.
There may still be a few non-bit-1 blocks that get orphaned after Aug 1,
because they're mined by old BIP141 nodes. But it seems like very few
miners won't be signaling either Segwit2x *or* BIP141 by then...
Make sense?
On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> Why do you say activation by August 1st is likely? That would require an
> entire difficulty adjustment period with >=95% bit1 signaling. That seems a
> tall order to organize in the scant few weeks remaining.
>
> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If segwit is activated before Aug 1, as now seems likely, there will be no
> split that day. But if activation is via Segwit2x (also likely), and at
> least some nodes do & some don't follow through with the HF 3mo later
> (again, likely), agreed w/ Greg that *then* we'll see a split - probably in
> Sep/Oct. How those two chains will match up and how the split will play
> out is anyone's guess...
>
>
>
> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Ironically, it looks like most of the segwit2x signaling miners are
> > faking it (because they're not signaling segwit which it requires).
> > It'll be unfortunate if some aren't faking it and start orphaning
> > their own blocks because they are failing to signal segwit.
>
> Well, they're doing some kind of "pre-signaling" in the coinbase at the
> moment, because the segwit2x project is still in alpha-phase according to
> the timeline. They're just showing commitment.
> I'm sure they will begin signaling on version bit 4/BIP91 as well as
> actually running a segwit2x node when the time comes.
>
>
> > As far as prevent a chain split goes, all those things
> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> > don't think that holds.
>
> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
> BIP148) node, because they wouldn't have the new consensus rule of
> requiring all blocks to signal for segwit.
> I don't believe there would be any long lasting chainsplit though (because
> of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get
> unlucky.
>
> Hampus
>
> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Because a large percentage of miners are indifferent, right now miners
>> have
>> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>
>> Miners can simply continuing signaling segwit, which will leave them
>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> what "segwit2x" is since they keep changing the actual definition and
>> do not have a specification; but last I saw the near-term behavior the
>> same as BIP91 but with a radically reduced activation window, so the
>> story would be the same there in the near term).
>>
>> Ironically, it looks like most of the segwit2x signaling miners are
>> faking it (because they're not signaling segwit which it requires).
>> It'll be unfortunate if some aren't faking it and start orphaning
>> their own blocks because they are failing to signal segwit.
>>
>> I don't think the rejection of segwit2x from Bitcoin's developers
>> could be any more resolute than what we've already seen:
>> https://en.bitcoin.it/wiki/Segwit_support
>>
>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > I think it is very naïve to assume that any shift would be temporary.
>> > We have a hard enough time getting miners to proactively upgrade to
>> > recent versions of the reference bitcoin daemon. If miners interpret
>> > the situation as being forced to run non-reference software in order
>> > to prevent a chain split because a lack of support from Bitcoin Core,
>> > that could be a one-way street.
>>
>> I think this is somewhat naive and sounds a lot like the repeat of the
>> previously debunked "XT" and "Classic" hysteria.
>>
>> There is a reason that segwit2x is pretty much unanimously rejected by
>> the technical community. And just like with XT/Classic/Unlimited
>> you'll continue to see a strong correlation with people who are
>> unwilling and unable to keep updating the software at an acceptable
>> level of quality-- esp. because the very founding on their fork is
>> predicated on discarding those properties.
>>
>> If miners want to go off and create an altcoin-- welp, thats something
>> they can always do, and nothing about that will force anyone to go
>> along with it.
>>
>> As far as prevent a chain split goes, all those things
>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>> don't think that holds.
>> _______________________________________________
>> 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/20170620/a7a99037/attachment-0001.html>

2023-06-07 18:03:28

- reply

📅 Original date posted:2017-06-20
📝 Original message:(That is: "...because they're mined by old non-Segwit2x nodes that *aren't
signaling bit 1 support*", ie, that support neither Segwit2x nor old segwit)
On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff <jacob.eliosoff at gmail.com>
wrote:
> I could be wrong, but the latest BIP91 implementation (also included in
> Segwit2x) cuts the activation period to 336 blocks (2.33 days). (This has
> been updated at https://github.com/bitcoin/bips/blob/master/bip-0091.
> mediawiki.) So if 80% of hashpower is actually running that code and
> signaling on bit 4 by July 25 or so, then those 80+% will start orphaning
> non-bit-1 blocks before Aug 1, and we avoid a split.
>
> There may still be a few non-bit-1 blocks that get orphaned after Aug 1,
> because they're mined by old BIP141 nodes. But it seems like very few
> miners won't be signaling either Segwit2x *or* BIP141 by then...
>
> Make sense?
>
>
> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <mark at friedenbach.org>
> wrote:
>
>> Why do you say activation by August 1st is likely? That would require an
>> entire difficulty adjustment period with >=95% bit1 signaling. That seems a
>> tall order to organize in the scant few weeks remaining.
>>
>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> If segwit is activated before Aug 1, as now seems likely, there will be
>> no split that day. But if activation is via Segwit2x (also likely), and at
>> least some nodes do & some don't follow through with the HF 3mo later
>> (again, likely), agreed w/ Greg that *then* we'll see a split - probably in
>> Sep/Oct. How those two chains will match up and how the split will play
>> out is anyone's guess...
>>
>>
>>
>> On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev" <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> > Ironically, it looks like most of the segwit2x signaling miners are
>> > faking it (because they're not signaling segwit which it requires).
>> > It'll be unfortunate if some aren't faking it and start orphaning
>> > their own blocks because they are failing to signal segwit.
>>
>> Well, they're doing some kind of "pre-signaling" in the coinbase at the
>> moment, because the segwit2x project is still in alpha-phase according to
>> the timeline. They're just showing commitment.
>> I'm sure they will begin signaling on version bit 4/BIP91 as well as
>> actually running a segwit2x node when the time comes.
>>
>>
>> > As far as prevent a chain split goes, all those things
>> > (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>> > don't think that holds.
>>
>> Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
>> BIP148) node, because they wouldn't have the new consensus rule of
>> requiring all blocks to signal for segwit.
>> I don't believe there would be any long lasting chainsplit though
>> (because of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if
>> we get unlucky.
>>
>> Hampus
>>
>> 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org>:
>>
>>> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > Because a large percentage of miners are indifferent, right now miners
>>> have
>>> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>>>
>>> Miners can simply continuing signaling segwit, which will leave them
>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>>> what "segwit2x" is since they keep changing the actual definition and
>>> do not have a specification; but last I saw the near-term behavior the
>>> same as BIP91 but with a radically reduced activation window, so the
>>> story would be the same there in the near term).
>>>
>>> Ironically, it looks like most of the segwit2x signaling miners are
>>> faking it (because they're not signaling segwit which it requires).
>>> It'll be unfortunate if some aren't faking it and start orphaning
>>> their own blocks because they are failing to signal segwit.
>>>
>>> I don't think the rejection of segwit2x from Bitcoin's developers
>>> could be any more resolute than what we've already seen:
>>> https://en.bitcoin.it/wiki/Segwit_support
>>>
>>> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > I think it is very naïve to assume that any shift would be temporary.
>>> > We have a hard enough time getting miners to proactively upgrade to
>>> > recent versions of the reference bitcoin daemon. If miners interpret
>>> > the situation as being forced to run non-reference software in order
>>> > to prevent a chain split because a lack of support from Bitcoin Core,
>>> > that could be a one-way street.
>>>
>>> I think this is somewhat naive and sounds a lot like the repeat of the
>>> previously debunked "XT" and "Classic" hysteria.
>>>
>>> There is a reason that segwit2x is pretty much unanimously rejected by
>>> the technical community. And just like with XT/Classic/Unlimited
>>> you'll continue to see a strong correlation with people who are
>>> unwilling and unable to keep updating the software at an acceptable
>>> level of quality-- esp. because the very founding on their fork is
>>> predicated on discarding those properties.
>>>
>>> If miners want to go off and create an altcoin-- welp, thats something
>>> they can always do, and nothing about that will force anyone to go
>>> along with it.
>>>
>>> As far as prevent a chain split goes, all those things
>>> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
>>> don't think that holds.
>>> _______________________________________________
>>> 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/20170620/ee28dc3b/attachment.html>

2023-06-07 18:03:27

- reply

📅 Original date posted:2017-06-20
📝 Original message:If segwit is activated before Aug 1, as now seems likely, there will be no
split that day. But if activation is via Segwit2x (also likely), and at
least some nodes do & some don't follow through with the HF 3mo later
(again, likely), agreed w/ Greg that *then* we'll see a split - probably in
Sep/Oct. How those two chains will match up and how the split will play
out is anyone's guess...
On Jun 20, 2017 6:16 PM, "Hampus Sjöberg via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
Well, they're doing some kind of "pre-signaling" in the coinbase at the
moment, because the segwit2x project is still in alpha-phase according to
the timeline. They're just showing commitment.
I'm sure they will begin signaling on version bit 4/BIP91 as well as
actually running a segwit2x node when the time comes.
> As far as prevent a chain split goes, all those things
> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> don't think that holds.
Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
BIP148) node, because they wouldn't have the new consensus rule of
requiring all blocks to signal for segwit.
I don't believe there would be any long lasting chainsplit though (because
of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get
unlucky.
Hampus
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Because a large percentage of miners are indifferent, right now miners
> have
> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>
> Miners can simply continuing signaling segwit, which will leave them
> at least soft-fork compatible with BIP148 and BIP91 (and god knows
> what "segwit2x" is since they keep changing the actual definition and
> do not have a specification; but last I saw the near-term behavior the
> same as BIP91 but with a radically reduced activation window, so the
> story would be the same there in the near term).
>
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
>
> I don't think the rejection of segwit2x from Bitcoin's developers
> could be any more resolute than what we've already seen:
> https://en.bitcoin.it/wiki/Segwit_support
>
> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I think it is very naïve to assume that any shift would be temporary.
> > We have a hard enough time getting miners to proactively upgrade to
> > recent versions of the reference bitcoin daemon. If miners interpret
> > the situation as being forced to run non-reference software in order
> > to prevent a chain split because a lack of support from Bitcoin Core,
> > that could be a one-way street.
>
> I think this is somewhat naive and sounds a lot like the repeat of the
> previously debunked "XT" and "Classic" hysteria.
>
> There is a reason that segwit2x is pretty much unanimously rejected by
> the technical community. And just like with XT/Classic/Unlimited
> you'll continue to see a strong correlation with people who are
> unwilling and unable to keep updating the software at an acceptable
> level of quality-- esp. because the very founding on their fork is
> predicated on discarding those properties.
>
> If miners want to go off and create an altcoin-- welp, thats something
> they can always do, and nothing about that will force anyone to go
> along with it.
>
> As far as prevent a chain split goes, all those things
> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> don't think that holds.
> _______________________________________________
> 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/20170620/dfa5b469/attachment-0001.html>

2023-06-07 18:02:52

- reply

📅 Original date posted:2017-06-10
📝 Original message:Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
split, because I may have left an overly pessimistic impression -
In short: the timing isn't as dire as I suggested, BUT unless concrete
progress on a plan starts taking shape, esp miner support, *the split is
indeed coming.*
THE GOOD NEWS: several refinements have been noted which could get BIP91
(or splitprotection, Segwit2x, etc) deployed faster:
- The lock-in window could be shortened, eg to splitprotection's 504 blocks
(3.5 days)
- Of course the 80% threshold could just be reduced, eg to
splitprotection's 65%
- BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
lock-in, rather than waiting another period until it "activates".
(Orphaning of non-bit-1-signaling blocks would probably also have to start
at or shortly after the same time [1].)
Combining these approaches, *July 26* is an approximate hard deadline for
>50% of miners to be running BIP91 in order to prevent the split. So,
significantly less tight than my previous June 30 (or my original,
erroneous "a few days ago").
THE BAD NEWS: no one should underestimate the steps that would need to be
completed by that deadline:
1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
itself, ...)
2. Implement and test it
3. Convince >50% of miners to run it [2]
4. Miners upgrade to the new software and begin signaling
In particular, #3: afaict a lot of convincing is still needed before miner
support for any of these reaches anything like 50%. (With the exception of
Segwit2x, but it has the additional handicap that it probably needs to
include deployable hard fork code, obviously ambitious in 1.5 months.)
[1] See Saicere's comment:
https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
discussion at https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011
.
[2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
signaling segwit support do *not* count, since they won't orphan non-bit-1
blocks. The impending split isn't between nodes that support segwit vs
don't, but between those that reject non-segwit-supporting blocks vs don't.
On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff <jacob.eliosoff at gmail.com>
wrote:
> Ah, two corrections:
> 1. I meant to include an option c): of course >50% of hashpower running
> BIP148 by Aug 1 avoids a split.
> 2. More seriously, I misrepresented BIP148's logic: it doesn't require
> segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks
> from Aug 1.
>
> I believe that means 80% of hashrate would need to be running BIP91
> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
> 27), not "a few days ago" as I claimed. So, tight timing, but not
> impossible.
>
> Sorry about the errors.
>
>
> On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff <jacob.eliosoff at gmail.com>
> wrote:
>
>> I've been trying to work out the expected interaction between James
>> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
>> use variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is
>> subtle so CORRECTIONS WELCOME, but my conclusions are:
>> 1. It's extremely unlikely BIP91-type logic can activate segwit in time
>> to avoid a BIP148 chain split.
>> 2. So, in practice all we can do is ensure the BIP148 split is as
>> painless as possible.
>>
>> REASONING: First, some dates. BIP148, whose deadline is already
>> deployed and thus unlikely to be postponed, starts orphaning non-segwit
>> blocks on midnight (GMT) the morning of August 1. Meanwhile, here are
>> Bitcoin's rough expected next four difficulty adjustment dates (they could
>> vary by ~1-3 days depending on block times, but it's unlikely to matter
>> here):
>> 1. June 17
>> 2. June 30
>> 3. July 13
>> 4. July 27
>>
>> If Segwit activates on adj date #5 or later (August), it will be too late
>> to avoid BIP148's split, which will have occurred the moment August began.
>> So, working backwards, and assuming we want compatibility with old BIP141
>> nodes:
>>
>> - Segwit MUST activate by adj #4 (~July 27)
>> - Therefore segwit MUST be locked in by adj #3 (~July 13: this is
>> inflexible, since this logic is in already-deployed BIP141 nodes)
>> - Therefore, I *think* >50% of hashpower needs to be BIP91 miners,
>> signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),
>> by adj #2 (June 30)?
>> - Therefore, as currently designed, BIP91 bit 4 must be locked in by adj
>> #1 (June 17)
>> - Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a
>> few days ago...
>>
>> There are ways parts of this could be sped up, eg, James' "rolling
>> 100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But
>> to be compatible with old BIP141 nodes, >50% of hashrate must be activated
>> BIP91 miners by ~June 30: there's no fudging that.
>>
>> So, it seems to me that to avoid the BIP148 split, one of two things
>> would have to happen:
>> a) 95% of hashrate start signaling bit 1 by ~June 30. Given current stat
>> is 32%, this would basically require magic.
>> b) BIP91 is deployed and >50% (80% or whatever) of hashrate is
>> *activated* BIP91 miners by ~June 30, ~3 weeks from now. Again, much too
>> soon.
>>
>> So, I think the BIP148 split is inevitable. I actually expect that few
>> parts of the ecosystem will join the fork, so disruption will be bearable.
>> But anyway let me know any flaws in the reasoning above.
>>
>> [1] https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
>> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -June/014508.html
>> [3] https://github.com/btc1/bitcoin/pull/11
>> [4] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
>> [5] https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170610/8122eddf/attachment.html>

2023-06-07 18:02:51

- reply

📅 Original date posted:2017-06-09
📝 Original message:I've been trying to work out the expected interaction between James
Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
use variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is
subtle so CORRECTIONS WELCOME, but my conclusions are:
1. It's extremely unlikely BIP91-type logic can activate segwit in time to
avoid a BIP148 chain split.
2. So, in practice all we can do is ensure the BIP148 split is as painless
as possible.
REASONING: First, some dates. BIP148, whose deadline is already deployed
and thus unlikely to be postponed, starts orphaning non-segwit blocks on
midnight (GMT) the morning of August 1. Meanwhile, here are Bitcoin's
rough expected next four difficulty adjustment dates (they could vary by
~1-3 days depending on block times, but it's unlikely to matter here):
1. June 17
2. June 30
3. July 13
4. July 27
If Segwit activates on adj date #5 or later (August), it will be too late
to avoid BIP148's split, which will have occurred the moment August began.
So, working backwards, and assuming we want compatibility with old BIP141
nodes:
- Segwit MUST activate by adj #4 (~July 27)
- Therefore segwit MUST be locked in by adj #3 (~July 13: this is
inflexible, since this logic is in already-deployed BIP141 nodes)
- Therefore, I *think* >50% of hashpower needs to be BIP91 miners,
signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),
by adj #2 (June 30)?
- Therefore, as currently designed, BIP91 bit 4 must be locked in by adj #1
(June 17)
- Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a few
days ago...
There are ways parts of this could be sped up, eg, James' "rolling
100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But
to be compatible with old BIP141 nodes, >50% of hashrate must be activated
BIP91 miners by ~June 30: there's no fudging that.
So, it seems to me that to avoid the BIP148 split, one of two things would
have to happen:
a) 95% of hashrate start signaling bit 1 by ~June 30. Given current stat
is 32%, this would basically require magic.
b) BIP91 is deployed and >50% (80% or whatever) of hashrate is *activated*
BIP91 miners by ~June 30, ~3 weeks from now. Again, much too soon.
So, I think the BIP148 split is inevitable. I actually expect that few
parts of the ecosystem will join the fork, so disruption will be bearable.
But anyway let me know any flaws in the reasoning above.
[1] https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014508.html
[3] https://github.com/btc1/bitcoin/pull/11
[4] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
[5] https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170609/e606bbb0/attachment-0001.html>

2023-06-07 18:02:51

- reply

📅 Original date posted:2017-06-09
📝 Original message:Ah, two corrections:
1. I meant to include an option c): of course >50% of hashpower running
BIP148 by Aug 1 avoids a split.
2. More seriously, I misrepresented BIP148's logic: it doesn't require
segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks
from Aug 1.
I believe that means 80% of hashrate would need to be running BIP91
(signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
27), not "a few days ago" as I claimed. So, tight timing, but not
impossible.
Sorry about the errors.
On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff <jacob.eliosoff at gmail.com>
wrote:
> I've been trying to work out the expected interaction between James
> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
> use variants of BIP91 activation) and the BIP148 UASF [4]. Some of this is
> subtle so CORRECTIONS WELCOME, but my conclusions are:
> 1. It's extremely unlikely BIP91-type logic can activate segwit in time to
> avoid a BIP148 chain split.
> 2. So, in practice all we can do is ensure the BIP148 split is as painless
> as possible.
>
> REASONING: First, some dates. BIP148, whose deadline is already deployed
> and thus unlikely to be postponed, starts orphaning non-segwit blocks on
> midnight (GMT) the morning of August 1. Meanwhile, here are Bitcoin's
> rough expected next four difficulty adjustment dates (they could vary by
> ~1-3 days depending on block times, but it's unlikely to matter here):
> 1. June 17
> 2. June 30
> 3. July 13
> 4. July 27
>
> If Segwit activates on adj date #5 or later (August), it will be too late
> to avoid BIP148's split, which will have occurred the moment August began.
> So, working backwards, and assuming we want compatibility with old BIP141
> nodes:
>
> - Segwit MUST activate by adj #4 (~July 27)
> - Therefore segwit MUST be locked in by adj #3 (~July 13: this is
> inflexible, since this logic is in already-deployed BIP141 nodes)
> - Therefore, I *think* >50% of hashpower needs to be BIP91 miners,
> signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),
> by adj #2 (June 30)?
> - Therefore, as currently designed, BIP91 bit 4 must be locked in by adj
> #1 (June 17)
> - Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a few
> days ago...
>
> There are ways parts of this could be sped up, eg, James' "rolling
> 100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner. But
> to be compatible with old BIP141 nodes, >50% of hashrate must be activated
> BIP91 miners by ~June 30: there's no fudging that.
>
> So, it seems to me that to avoid the BIP148 split, one of two things would
> have to happen:
> a) 95% of hashrate start signaling bit 1 by ~June 30. Given current stat
> is 32%, this would basically require magic.
> b) BIP91 is deployed and >50% (80% or whatever) of hashrate is *activated*
> BIP91 miners by ~June 30, ~3 weeks from now. Again, much too soon.
>
> So, I think the BIP148 split is inevitable. I actually expect that few
> parts of the ecosystem will join the fork, so disruption will be bearable.
> But anyway let me know any flaws in the reasoning above.
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2017-June/014508.html
> [3] https://github.com/btc1/bitcoin/pull/11
> [4] https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> [5] https://github.com/btc1/bitcoin/pull/6#issuecomment-305917729
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170609/e004899e/attachment-0001.html>

2023-06-07 18:02:38

- reply

📅 Original date posted:2017-06-07
📝 Original message:You're missing my point. "As soon as a simple majority supports it" - what
is "it"? BIP148? Or "deferring to the miner consensus on BIP148"? It's
the difference between supporting one side of a vote, vs supporting
deferral to the outcome of the vote.
Or if you mean, the safe thing for miners is to orphan non-segwit blocks
Aug 1 *regardless* of the miner consensus (since the economic consensus
might differ), then there's zero need for this BIP: they should just run
BIP148.
As I said: this BIP should be corrected to only orphan if >50% signal for
BIP148. Or, define two bits, one meaning "I support BIP148," the other "I
will go w/ the miner majority on BIP148." Fudging them this way is
deceptive.
On Jun 7, 2017 2:05 PM, "Erik Aronesty" <erik at q32.com> wrote:
> But passing it off as the safest defense is bad faith.
Without this option, a miner has to guess whether a split will be
economically impacting. With this option, his miner will automatically
switch to the chain least likely to get wiped out... as soon as a simple
majority of miners supports it.
On Wed, Jun 7, 2017 at 12:44 PM, Jacob Eliosoff <jacob.eliosoff at gmail.com>
wrote:
> This is not the safest defense against a split. If 70% of miners run
> "splitprotection", and 0.1% run BIP148, there's no "safety"/"defense"
> reason for splitprotection to activate segwit. It should only do so if
> *BIP148* support (NB: not just segwit support!) >50%.
>
> The truly defensive logic is "If the majority supports orphaning
> non-segwit blocks starting Aug 1, I'll join them."
>
> If the real goal of this BIP is to induce miners to run segwit, then fair
> enough. But passing it off as the safest defense is bad faith.
>
>
> On Wed, Jun 7, 2017 at 10:10 AM, Erik Aronesty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> This is, by far, the safest way for miners to quickly defend against a
>> chain split, much better than a -bip148 option. This allows miners to
>> defend themselves, with very little risk, since the defense is only
>> activated if the majority of miners do so. I would move for a very rapid
>> deployment. Only miners would need to upgrade. Regular users would not
>> have to concern themselves with this release.
>>
>> On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I think even 55% would probably work out fine simply due to incentive
>>> structures, once signalling is over 51% it's then clear to miners that
>>> non-signalling blocks will be orphaned and the rest will rapidly
>>> update to splitprotection/BIP148. The purpose of this BIP is to reduce
>>> chain split risk for BIP148 since it's looking like BIP148 is going to
>>> be run by a non-insignificant percentage of the economy at a minimum.
>>>
>>> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <contact at taoeffect.com>
>>> wrote:
>>> > See thread on replay attacks for why activating regardless of
>>> threshold is a
>>> > bad idea [1].
>>> >
>>> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
>>> > difficult for miners to hold together in opposition to Core. It gives
>>> Core
>>> > more leverage in negotiations.
>>> >
>>> > If they don't activate with 80%, Core can release another BIP to
>>> reduce it
>>> > to 75%.
>>> >
>>> > Each threshold reduction makes it both more likely to succeed, but also
>>> > increases the likelihood of harm to the ecosystem.
>>> >
>>> > Cheers,
>>> > Greg
>>> >
>>> > [1]
>>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>>> -June/014497.html
>>> >
>>> > --
>>> > Please do not email me anything that you are not comfortable also
>>> sharing
>>> > with the NSA.
>>> >
>>> > On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1 at gmail.com>
>>> > wrote:
>>> >
>>> > This is a BIP8 style soft fork so mandatory signalling will be active
>>> > after Aug 1st regardless.
>>> >
>>> > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com>
>>> wrote:
>>> >
>>> > What is the probability that a 65% threshold is too low and can allow a
>>> > "surprise miner attack", whereby miners are kept offline before the
>>> > deadline, and brought online immediately after, creating potential
>>> havoc?
>>> >
>>> > (Nit: "simple majority" usually refers to >50%, I think, might cause
>>> > confusion.)
>>> >
>>> > -Greg Slepak
>>> >
>>> > --
>>> > Please do not email me anything that you are not comfortable also
>>> sharing
>>> > with the NSA.
>>> >
>>> > On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
>>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> >
>>> > Due to the proposed calendar(https://segwit2x.github.io/) for the
>>> > SegWit2x agreement being too slow to activate SegWit mandatory
>>> > signalling ahead of BIP148 using BIP91 I would like to propose another
>>> > option that miners can use to prevent a chain split ahead of the Aug
>>> > 1st BIP148 activation date.
>>> >
>>> > The splitprotection soft fork is essentially BIP91 but using BIP8
>>> > instead of BIP9 with a lower activation threshold and immediate
>>> > mandatory signalling lock-in. This allows for a majority of miners to
>>> > activate mandatory SegWit signalling and prevent a potential chain
>>> > split ahead of BIP148 activation.
>>> >
>>> > This BIP allows for miners to respond to market forces quickly ahead
>>> > of BIP148 activation by signalling for splitprotection. Any miners
>>> > already running BIP148 should be encouraged to use splitprotection.
>>> >
>>> > <pre>
>>> > BIP: splitprotection
>>> > Layer: Consensus (soft fork)
>>> > Title: User Activated Soft Fork Split Protection
>>> > Author: James Hilliard <james.hilliard1 at gmail.com>
>>> > Comments-Summary: No comments yet.
>>> > Comments-URI:
>>> > Status: Draft
>>> > Type: Standards Track
>>> > Created: 2017-05-22
>>> > License: BSD-3-Clause
>>> > CC0-1.0
>>> > </pre>
>>> >
>>> > ==Abstract==
>>> >
>>> > This document specifies a coordination mechanism for a simple majority
>>> > of miners to prevent a chain split ahead of BIP148 activation.
>>> >
>>> > ==Definitions==
>>> >
>>> > "existing segwit deployment" refer to the BIP9 "segwit" deployment
>>> > using bit 1, between November 15th 2016 and November 15th 2017 to
>>> > activate BIP141, BIP143 and BIP147.
>>> >
>>> > ==Motivation==
>>> >
>>> > The biggest risk of BIP148 is an extended chain split, this BIP
>>> > provides a way for a simple majority of miners to eliminate that risk.
>>> >
>>> > This BIP provides a way for a simple majority of miners to coordinate
>>> > activation of the existing segwit deployment with less than 95%
>>> > hashpower before BIP148 activation. Due to time constraints unless
>>> > immediately deployed BIP91 will likely not be able to enforce
>>> > mandatory signalling of segwit before the Aug 1st activation of
>>> > BIP148. This BIP provides a method for rapid miner activation of
>>> > SegWit mandatory signalling ahead of the BIP148 activation date. Since
>>> > the primary goal of this BIP is to reduce the chance of an extended
>>> > chain split as much as possible we activate using a simple miner
>>> > majority of 65% over a 504 block interval rather than a higher
>>> > percentage. This BIP also allows miners to signal their intention to
>>> > run BIP148 in order to prevent a chain split.
>>> >
>>> > ==Specification==
>>> >
>>> > While this BIP is active, all blocks must set the nVersion header top
>>> > 3 bits to 001 together with bit field (1<<1) (according to the
>>> > existing segwit deployment). Blocks that do not signal as required
>>> > will be rejected.
>>> >
>>> > ==Deployment==
>>> >
>>> > This BIP will be deployed by "version bits" with a 65%(this can be
>>> > adjusted if desired) activation threshold BIP9 with the name
>>> > "splitprotecion" and using bit 2.
>>> >
>>> > This BIP starts immediately and is a BIP8 style soft fork since
>>> > mandatory signalling will start on midnight August 1st 2017 (epoch
>>> > time 1501545600) regardless of whether or not this BIP has reached its
>>> > own signalling threshold. This BIP will cease to be active when segwit
>>> > is locked-in.
>>> >
>>> > === Reference implementation ===
>>> >
>>> > <pre>
>>> > // Check if Segregated Witness is Locked In
>>> > bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>>> > Consensus::Params& params)
>>> > {
>>> > LOCK(cs_main);
>>> > return (VersionBitsState(pindexPrev, params,
>>> > Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>>> > THRESHOLD_LOCKED_IN);
>>> > }
>>> >
>>> > // SPLITPROTECTION mandatory segwit signalling.
>>> > if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>>> > Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
>>> > THRESHOLD_LOCKED_IN &&
>>> > !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>>> > // Segwit is not locked in
>>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>>> > and is not active.
>>> > {
>>> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>>> > VERSIONBITS_TOP_BITS;
>>> > bool fSegbit = (pindex->nVersion &
>>> > VersionBitsMask(chainparams.GetConsensus(),
>>> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
>>> > if (!(fVersionBits && fSegbit)) {
>>> > return state.DoS(0, error("ConnectBlock(): relayed block must
>>> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>>> > }
>>> > }
>>> >
>>> > // BIP148 mandatory segwit signalling.
>>> > int64_t nMedianTimePast = pindex->GetMedianTimePast();
>>> > if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00
>>> UTC
>>> > (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
>>> > (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>>> > // Segwit is not locked in
>>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
>>> > // and is not active.
>>> > {
>>> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>>> > VERSIONBITS_TOP_BITS;
>>> > bool fSegbit = (pindex->nVersion &
>>> > VersionBitsMask(chainparams.GetConsensus(),
>>> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
>>> > if (!(fVersionBits && fSegbit)) {
>>> > return state.DoS(0, error("ConnectBlock(): relayed block must
>>> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>>> > }
>>> > }
>>> > </pre>
>>> >
>>> > https://github.com/bitcoin/bitcoin/compare/0.14...jameshilli
>>> ard:splitprotection-v0.14.1
>>> >
>>> > ==Backwards Compatibility==
>>> >
>>> > This deployment is compatible with the existing "segwit" bit 1
>>> > deployment scheduled between midnight November 15th, 2016 and midnight
>>> > November 15th, 2017. This deployment is also compatible with the
>>> > existing BIP148 deployment. This BIP is compatible with BIP91 only if
>>> > BIP91 activates before it and before BIP148. Miners will need to
>>> > upgrade their nodes to support splitprotection otherwise they may
>>> > build on top of an invalid block. While this bip is active users
>>> > should either upgrade to splitprotection or wait for additional
>>> > confirmations when accepting payments.
>>> >
>>> > ==Rationale==
>>> >
>>> > Historically we have used IsSuperMajority() to activate soft forks
>>> > such as BIP66 which has a mandatory signalling requirement for miners
>>> > once activated, this ensures that miners are aware of new rules being
>>> > enforced. This technique can be leveraged to lower the signalling
>>> > threshold of a soft fork while it is in the process of being deployed
>>> > in a backwards compatible way. We also use a BIP8 style timeout to
>>> > ensure that this BIP is compatible with BIP148 and that BIP148
>>> > compatible mandatory signalling activates regardless of miner
>>> > signalling levels.
>>> >
>>> > By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
>>> > deployment, this BIP can cause the existing "segwit" deployment to
>>> > activate without needing to release a new deployment. As we approach
>>> > BIP148 activation it may be desirable for a majority of miners to have
>>> > a method that will ensure that there is no chain split.
>>> >
>>> > ==References==
>>> >
>>> > *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/20
>>> 17-March/013714.html
>>> > Mailing list discussion]
>>> > *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cp
>>> p#L1281-L1283
>>> > P2SH flag day activation]
>>> > *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
>>> > *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
>>> > *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
>>> > *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
>>> > *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
>>> > Version 0 Witness Program]]
>>> > *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
>>> malleability]]
>>> > *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit
>>> deployment]]
>>> > *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
>>> > *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
>>> benefits]
>>> >
>>> > ==Copyright==
>>> >
>>> > This document is dual licensed as BSD 3-clause, and Creative Commons
>>> > CC0 1.0 Universal.
>>> > _______________________________________________
>>> > 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/20170607/e1a7345e/attachment-0001.html>

2023-06-07 18:02:36

- reply

📅 Original date posted:2017-06-07
📝 Original message:This is not the safest defense against a split. If 70% of miners run
"splitprotection", and 0.1% run BIP148, there's no "safety"/"defense"
reason for splitprotection to activate segwit. It should only do so if
*BIP148* support (NB: not just segwit support!) >50%.
The truly defensive logic is "If the majority supports orphaning non-segwit
blocks starting Aug 1, I'll join them."
If the real goal of this BIP is to induce miners to run segwit, then fair
enough. But passing it off as the safest defense is bad faith.
On Wed, Jun 7, 2017 at 10:10 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is, by far, the safest way for miners to quickly defend against a
> chain split, much better than a -bip148 option. This allows miners to
> defend themselves, with very little risk, since the defense is only
> activated if the majority of miners do so. I would move for a very rapid
> deployment. Only miners would need to upgrade. Regular users would not
> have to concern themselves with this release.
>
> On Wed, Jun 7, 2017 at 6:13 AM, James Hilliard via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think even 55% would probably work out fine simply due to incentive
>> structures, once signalling is over 51% it's then clear to miners that
>> non-signalling blocks will be orphaned and the rest will rapidly
>> update to splitprotection/BIP148. The purpose of this BIP is to reduce
>> chain split risk for BIP148 since it's looking like BIP148 is going to
>> be run by a non-insignificant percentage of the economy at a minimum.
>>
>> On Wed, Jun 7, 2017 at 12:20 AM, Tao Effect <contact at taoeffect.com>
>> wrote:
>> > See thread on replay attacks for why activating regardless of threshold
>> is a
>> > bad idea [1].
>> >
>> > BIP91 OTOH seems perfectly reasonable. 80% instead of 95% makes it more
>> > difficult for miners to hold together in opposition to Core. It gives
>> Core
>> > more leverage in negotiations.
>> >
>> > If they don't activate with 80%, Core can release another BIP to reduce
>> it
>> > to 75%.
>> >
>> > Each threshold reduction makes it both more likely to succeed, but also
>> > increases the likelihood of harm to the ecosystem.
>> >
>> > Cheers,
>> > Greg
>> >
>> > [1]
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>> -June/014497.html
>> >
>> > --
>> > Please do not email me anything that you are not comfortable also
>> sharing
>> > with the NSA.
>> >
>> > On Jun 6, 2017, at 6:54 PM, James Hilliard <james.hilliard1 at gmail.com>
>> > wrote:
>> >
>> > This is a BIP8 style soft fork so mandatory signalling will be active
>> > after Aug 1st regardless.
>> >
>> > On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com>
>> wrote:
>> >
>> > What is the probability that a 65% threshold is too low and can allow a
>> > "surprise miner attack", whereby miners are kept offline before the
>> > deadline, and brought online immediately after, creating potential
>> havoc?
>> >
>> > (Nit: "simple majority" usually refers to >50%, I think, might cause
>> > confusion.)
>> >
>> > -Greg Slepak
>> >
>> > --
>> > Please do not email me anything that you are not comfortable also
>> sharing
>> > with the NSA.
>> >
>> > On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
>> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > Due to the proposed calendar(https://segwit2x.github.io/) for the
>> > SegWit2x agreement being too slow to activate SegWit mandatory
>> > signalling ahead of BIP148 using BIP91 I would like to propose another
>> > option that miners can use to prevent a chain split ahead of the Aug
>> > 1st BIP148 activation date.
>> >
>> > The splitprotection soft fork is essentially BIP91 but using BIP8
>> > instead of BIP9 with a lower activation threshold and immediate
>> > mandatory signalling lock-in. This allows for a majority of miners to
>> > activate mandatory SegWit signalling and prevent a potential chain
>> > split ahead of BIP148 activation.
>> >
>> > This BIP allows for miners to respond to market forces quickly ahead
>> > of BIP148 activation by signalling for splitprotection. Any miners
>> > already running BIP148 should be encouraged to use splitprotection.
>> >
>> > <pre>
>> > BIP: splitprotection
>> > Layer: Consensus (soft fork)
>> > Title: User Activated Soft Fork Split Protection
>> > Author: James Hilliard <james.hilliard1 at gmail.com>
>> > Comments-Summary: No comments yet.
>> > Comments-URI:
>> > Status: Draft
>> > Type: Standards Track
>> > Created: 2017-05-22
>> > License: BSD-3-Clause
>> > CC0-1.0
>> > </pre>
>> >
>> > ==Abstract==
>> >
>> > This document specifies a coordination mechanism for a simple majority
>> > of miners to prevent a chain split ahead of BIP148 activation.
>> >
>> > ==Definitions==
>> >
>> > "existing segwit deployment" refer to the BIP9 "segwit" deployment
>> > using bit 1, between November 15th 2016 and November 15th 2017 to
>> > activate BIP141, BIP143 and BIP147.
>> >
>> > ==Motivation==
>> >
>> > The biggest risk of BIP148 is an extended chain split, this BIP
>> > provides a way for a simple majority of miners to eliminate that risk.
>> >
>> > This BIP provides a way for a simple majority of miners to coordinate
>> > activation of the existing segwit deployment with less than 95%
>> > hashpower before BIP148 activation. Due to time constraints unless
>> > immediately deployed BIP91 will likely not be able to enforce
>> > mandatory signalling of segwit before the Aug 1st activation of
>> > BIP148. This BIP provides a method for rapid miner activation of
>> > SegWit mandatory signalling ahead of the BIP148 activation date. Since
>> > the primary goal of this BIP is to reduce the chance of an extended
>> > chain split as much as possible we activate using a simple miner
>> > majority of 65% over a 504 block interval rather than a higher
>> > percentage. This BIP also allows miners to signal their intention to
>> > run BIP148 in order to prevent a chain split.
>> >
>> > ==Specification==
>> >
>> > While this BIP is active, all blocks must set the nVersion header top
>> > 3 bits to 001 together with bit field (1<<1) (according to the
>> > existing segwit deployment). Blocks that do not signal as required
>> > will be rejected.
>> >
>> > ==Deployment==
>> >
>> > This BIP will be deployed by "version bits" with a 65%(this can be
>> > adjusted if desired) activation threshold BIP9 with the name
>> > "splitprotecion" and using bit 2.
>> >
>> > This BIP starts immediately and is a BIP8 style soft fork since
>> > mandatory signalling will start on midnight August 1st 2017 (epoch
>> > time 1501545600) regardless of whether or not this BIP has reached its
>> > own signalling threshold. This BIP will cease to be active when segwit
>> > is locked-in.
>> >
>> > === Reference implementation ===
>> >
>> > <pre>
>> > // Check if Segregated Witness is Locked In
>> > bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>> > Consensus::Params& params)
>> > {
>> > LOCK(cs_main);
>> > return (VersionBitsState(pindexPrev, params,
>> > Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>> > THRESHOLD_LOCKED_IN);
>> > }
>> >
>> > // SPLITPROTECTION mandatory segwit signalling.
>> > if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>> > Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
>> > THRESHOLD_LOCKED_IN &&
>> > !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> > // Segwit is not locked in
>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>> > and is not active.
>> > {
>> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>> > VERSIONBITS_TOP_BITS;
>> > bool fSegbit = (pindex->nVersion &
>> > VersionBitsMask(chainparams.GetConsensus(),
>> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> > if (!(fVersionBits && fSegbit)) {
>> > return state.DoS(0, error("ConnectBlock(): relayed block must
>> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> > }
>> > }
>> >
>> > // BIP148 mandatory segwit signalling.
>> > int64_t nMedianTimePast = pindex->GetMedianTimePast();
>> > if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
>> > (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
>> > (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>> > // Segwit is not locked in
>> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
>> > // and is not active.
>> > {
>> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>> > VERSIONBITS_TOP_BITS;
>> > bool fSegbit = (pindex->nVersion &
>> > VersionBitsMask(chainparams.GetConsensus(),
>> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
>> > if (!(fVersionBits && fSegbit)) {
>> > return state.DoS(0, error("ConnectBlock(): relayed block must
>> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> > }
>> > }
>> > </pre>
>> >
>> > https://github.com/bitcoin/bitcoin/compare/0.14...jameshilli
>> ard:splitprotection-v0.14.1
>> >
>> > ==Backwards Compatibility==
>> >
>> > This deployment is compatible with the existing "segwit" bit 1
>> > deployment scheduled between midnight November 15th, 2016 and midnight
>> > November 15th, 2017. This deployment is also compatible with the
>> > existing BIP148 deployment. This BIP is compatible with BIP91 only if
>> > BIP91 activates before it and before BIP148. Miners will need to
>> > upgrade their nodes to support splitprotection otherwise they may
>> > build on top of an invalid block. While this bip is active users
>> > should either upgrade to splitprotection or wait for additional
>> > confirmations when accepting payments.
>> >
>> > ==Rationale==
>> >
>> > Historically we have used IsSuperMajority() to activate soft forks
>> > such as BIP66 which has a mandatory signalling requirement for miners
>> > once activated, this ensures that miners are aware of new rules being
>> > enforced. This technique can be leveraged to lower the signalling
>> > threshold of a soft fork while it is in the process of being deployed
>> > in a backwards compatible way. We also use a BIP8 style timeout to
>> > ensure that this BIP is compatible with BIP148 and that BIP148
>> > compatible mandatory signalling activates regardless of miner
>> > signalling levels.
>> >
>> > By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
>> > deployment, this BIP can cause the existing "segwit" deployment to
>> > activate without needing to release a new deployment. As we approach
>> > BIP148 activation it may be desirable for a majority of miners to have
>> > a method that will ensure that there is no chain split.
>> >
>> > ==References==
>> >
>> > *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
>> 2017-March/013714.html
>> > Mailing list discussion]
>> > *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cp
>> p#L1281-L1283
>> > P2SH flag day activation]
>> > *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
>> > *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
>> > *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
>> > *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
>> > *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
>> > Version 0 Witness Program]]
>> > *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
>> malleability]]
>> > *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
>> > *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
>> > *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
>> benefits]
>> >
>> > ==Copyright==
>> >
>> > This document is dual licensed as BSD 3-clause, and Creative Commons
>> > CC0 1.0 Universal.
>> > _______________________________________________
>> > 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/20170607/308e84ea/attachment-0001.html>

2023-06-07 18:02:33

- reply

📅 Original date posted:2017-06-07
📝 Original message:While this isn't an unreasonable proposal, it will orphan blocks from any
miner who isn't running it (or BIP148) by Aug 1, right? That seems rather
rushed for a non-backwards-compatible SF, especially since in practice,
miners are unlikely to deploy it until it comes bundled with some version
of the Segwit2x HF code.
I realize this is a touchy topic but - how much hard evidence is there that
there *will* be significant disruption if miners simply ignore both this
and BIP148? Correct me but afaict, BIP148 has ~0% hashrate support.
Unless the HF code is ready and agree on soon (say by Jul 1), my vote is to
keep the main chain backwards-compatible, especially if evidence of miner
support for BIP148 doesn't materialize soon. It seems less disruptive for
recently-deployed BIP148 nodes to revert than to ask every miner in the
system to quickly upgrade or get orphaned.
Just my view, I respect that others will differ.
On Tue, Jun 6, 2017 at 9:54 PM, James Hilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This is a BIP8 style soft fork so mandatory signalling will be active
> after Aug 1st regardless.
>
> On Tue, Jun 6, 2017 at 8:51 PM, Tao Effect <contact at taoeffect.com> wrote:
> > What is the probability that a 65% threshold is too low and can allow a
> > "surprise miner attack", whereby miners are kept offline before the
> > deadline, and brought online immediately after, creating potential havoc?
> >
> > (Nit: "simple majority" usually refers to >50%, I think, might cause
> > confusion.)
> >
> > -Greg Slepak
> >
> > --
> > Please do not email me anything that you are not comfortable also sharing
> > with the NSA.
> >
> > On Jun 6, 2017, at 5:56 PM, James Hilliard via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Due to the proposed calendar(https://segwit2x.github.io/) for the
> > SegWit2x agreement being too slow to activate SegWit mandatory
> > signalling ahead of BIP148 using BIP91 I would like to propose another
> > option that miners can use to prevent a chain split ahead of the Aug
> > 1st BIP148 activation date.
> >
> > The splitprotection soft fork is essentially BIP91 but using BIP8
> > instead of BIP9 with a lower activation threshold and immediate
> > mandatory signalling lock-in. This allows for a majority of miners to
> > activate mandatory SegWit signalling and prevent a potential chain
> > split ahead of BIP148 activation.
> >
> > This BIP allows for miners to respond to market forces quickly ahead
> > of BIP148 activation by signalling for splitprotection. Any miners
> > already running BIP148 should be encouraged to use splitprotection.
> >
> > <pre>
> > BIP: splitprotection
> > Layer: Consensus (soft fork)
> > Title: User Activated Soft Fork Split Protection
> > Author: James Hilliard <james.hilliard1 at gmail.com>
> > Comments-Summary: No comments yet.
> > Comments-URI:
> > Status: Draft
> > Type: Standards Track
> > Created: 2017-05-22
> > License: BSD-3-Clause
> > CC0-1.0
> > </pre>
> >
> > ==Abstract==
> >
> > This document specifies a coordination mechanism for a simple majority
> > of miners to prevent a chain split ahead of BIP148 activation.
> >
> > ==Definitions==
> >
> > "existing segwit deployment" refer to the BIP9 "segwit" deployment
> > using bit 1, between November 15th 2016 and November 15th 2017 to
> > activate BIP141, BIP143 and BIP147.
> >
> > ==Motivation==
> >
> > The biggest risk of BIP148 is an extended chain split, this BIP
> > provides a way for a simple majority of miners to eliminate that risk.
> >
> > This BIP provides a way for a simple majority of miners to coordinate
> > activation of the existing segwit deployment with less than 95%
> > hashpower before BIP148 activation. Due to time constraints unless
> > immediately deployed BIP91 will likely not be able to enforce
> > mandatory signalling of segwit before the Aug 1st activation of
> > BIP148. This BIP provides a method for rapid miner activation of
> > SegWit mandatory signalling ahead of the BIP148 activation date. Since
> > the primary goal of this BIP is to reduce the chance of an extended
> > chain split as much as possible we activate using a simple miner
> > majority of 65% over a 504 block interval rather than a higher
> > percentage. This BIP also allows miners to signal their intention to
> > run BIP148 in order to prevent a chain split.
> >
> > ==Specification==
> >
> > While this BIP is active, all blocks must set the nVersion header top
> > 3 bits to 001 together with bit field (1<<1) (according to the
> > existing segwit deployment). Blocks that do not signal as required
> > will be rejected.
> >
> > ==Deployment==
> >
> > This BIP will be deployed by "version bits" with a 65%(this can be
> > adjusted if desired) activation threshold BIP9 with the name
> > "splitprotecion" and using bit 2.
> >
> > This BIP starts immediately and is a BIP8 style soft fork since
> > mandatory signalling will start on midnight August 1st 2017 (epoch
> > time 1501545600) regardless of whether or not this BIP has reached its
> > own signalling threshold. This BIP will cease to be active when segwit
> > is locked-in.
> >
> > === Reference implementation ===
> >
> > <pre>
> > // Check if Segregated Witness is Locked In
> > bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> > Consensus::Params& params)
> > {
> > LOCK(cs_main);
> > return (VersionBitsState(pindexPrev, params,
> > Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> > THRESHOLD_LOCKED_IN);
> > }
> >
> > // SPLITPROTECTION mandatory segwit signalling.
> > if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> > Consensus::DEPLOYMENT_SPLITPROTECTION, versionbitscache) ==
> > THRESHOLD_LOCKED_IN &&
> > !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> > // Segwit is not locked in
> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> > and is not active.
> > {
> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> > VERSIONBITS_TOP_BITS;
> > bool fSegbit = (pindex->nVersion &
> > VersionBitsMask(chainparams.GetConsensus(),
> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
> > if (!(fVersionBits && fSegbit)) {
> > return state.DoS(0, error("ConnectBlock(): relayed block must
> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> > }
> > }
> >
> > // BIP148 mandatory segwit signalling.
> > int64_t nMedianTimePast = pindex->GetMedianTimePast();
> > if ( (nMedianTimePast >= 1501545600) && // Tue 01 Aug 2017 00:00:00 UTC
> > (nMedianTimePast <= 1510704000) && // Wed 15 Nov 2017 00:00:00 UTC
> > (!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> > // Segwit is not locked in
> > !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) )
> > // and is not active.
> > {
> > bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> > VERSIONBITS_TOP_BITS;
> > bool fSegbit = (pindex->nVersion &
> > VersionBitsMask(chainparams.GetConsensus(),
> > Consensus::DEPLOYMENT_SEGWIT)) != 0;
> > if (!(fVersionBits && fSegbit)) {
> > return state.DoS(0, error("ConnectBlock(): relayed block must
> > signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> > }
> > }
> > </pre>
> >
> > https://github.com/bitcoin/bitcoin/compare/0.14...
> jameshilliard:splitprotection-v0.14.1
> >
> > ==Backwards Compatibility==
> >
> > This deployment is compatible with the existing "segwit" bit 1
> > deployment scheduled between midnight November 15th, 2016 and midnight
> > November 15th, 2017. This deployment is also compatible with the
> > existing BIP148 deployment. This BIP is compatible with BIP91 only if
> > BIP91 activates before it and before BIP148. Miners will need to
> > upgrade their nodes to support splitprotection otherwise they may
> > build on top of an invalid block. While this bip is active users
> > should either upgrade to splitprotection or wait for additional
> > confirmations when accepting payments.
> >
> > ==Rationale==
> >
> > Historically we have used IsSuperMajority() to activate soft forks
> > such as BIP66 which has a mandatory signalling requirement for miners
> > once activated, this ensures that miners are aware of new rules being
> > enforced. This technique can be leveraged to lower the signalling
> > threshold of a soft fork while it is in the process of being deployed
> > in a backwards compatible way. We also use a BIP8 style timeout to
> > ensure that this BIP is compatible with BIP148 and that BIP148
> > compatible mandatory signalling activates regardless of miner
> > signalling levels.
> >
> > By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> > deployment, this BIP can cause the existing "segwit" deployment to
> > activate without needing to release a new deployment. As we approach
> > BIP148 activation it may be desirable for a majority of miners to have
> > a method that will ensure that there is no chain split.
> >
> > ==References==
> >
> > *[https://lists.linuxfoundation.org/pipermail/
> bitcoin-dev/2017-March/013714.html
> > Mailing list discussion]
> > *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.
> cpp#L1281-L1283
> > P2SH flag day activation]
> > *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> > *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> > *[[bip-0091.mediawiki|BIP91 Reduced threshold Segwit MASF]]
> > *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> > *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> > Version 0 Witness Program]]
> > *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element
> malleability]]
> > *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> > *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> > *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit
> benefits]
> >
> > ==Copyright==
> >
> > This document is dual licensed as BSD 3-clause, and Creative Commons
> > CC0 1.0 Universal.
> > _______________________________________________
> > 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/20170607/27553471/attachment-0001.html>

2023-06-07 18:01:50

- reply

📅 Original date posted:2017-05-31
📝 Original message:Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
quadratic hashing risks, and maybe James' 10KB is too ambitious; but even
if so, a simple 1MB tx size limit would clearly do the trick. The broader
point is that quadratic hashing is not a compelling reason to keep
blockmaxsize post-HF: does someone have a better one?
On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> That would invalidate any pre-signed transactions that are currently out
> there. You can't just change the rules out from under people.
>
>
> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
>
>> The 1MB classic block size prevents quadratic hashing
>> problems from being any worse than they are today.
>>
>>
> Add a transaction-size limit of, say, 10kb and the quadratic hashing
> problem is a non-issue. Donezo.
>
> _______________________________________________
> 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/20170530/a232820b/attachment.html>

2023-06-07 18:01:48

- reply

📅 Original date posted:2017-05-30
📝 Original message:I'd like to know this too. Is it just that a 4MB blockmaxweight would
theoretically allow ~4MB blocks (if ~all witness data), which is too big?
Or is there a more subtle reason we still need blockmaxsize after a HF?
On May 30, 2017 9:28 AM, "Jorge Timón via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
Why not simply remove the (redundant after sw activation) 1 mb size
limit check and increasing the weight limit without changing the
discount or having 2 limits?
On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Personally, I would prefer if a 2MB lock-in that uses BIP103 for the
timing.
>
> I think up to 20% per year can be absorbed by averages in
bandwidth/CPU/RAM
> growth, of which bandwidth seems the most constraining.
>
> - Erik
>
>
> On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> In light of some recent discussions, I wrote up this BIP for a real 2 MB
>> block
>> size hardfork following Segwit BIP148 activation. This is not part of any
>> agreement I am party to, nor anything of that sort. Just something to
>> throw
>> out there as a possible (and realistic) option.
>>
>> Note that I cannot recommend this to be adopted, since frankly 1 MB
blocks
>> really are still too large, and this blunt-style hardfork quite risky
even
>> with consensus. But if the community wishes to adopt (by unanimous
>> consensus)
>> a 2 MB block size hardfork, this is probably the best way to do it right
>> now.
>> The only possible way to improve on this IMO would be to integrate it
into
>> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size
>> HF
>> improvements).
>>
>> I have left Author blank, as I do not intend to personally champion this.
>> Before it may be assigned a BIP number, someone else will need to step up
>> to
>> take on that role. Motivation and Rationale are blank because I do not
>> personally think there is any legitimate rationale for such a hardfork at
>> this
>> time; if someone adopts this BIP, they should complete these sections. (I
>> can
>> push a git branch with the BIP text if someone wants to fork it.)
>>
>> <pre>
>> BIP: ?
>> Layer: Consensus (hard fork)
>> Title: Post-segwit 2 MB block size hardfork
>> Author: FIXME
>> Comments-Summary: No comments yet.
>> Comments-URI: ?
>> Status: Draft
>> Type: Standards Track
>> Created: 2017-05-22
>> License: BSD-2-Clause
>> </pre>
>>
>> ==Abstract==
>>
>> Legacy Bitcoin transactions are given the witness discount, and a block
>> size
>> limit of 2 MB is imposed.
>>
>> ==Copyright==
>>
>> This BIP is licensed under the BSD 2-clause license.
>>
>> ==Specification==
>>
>> Upon activation, a block size limit of 2000000 bytes is enforced.
>> The block weight limit remains at 4000000 WU.
>>
>> The calculation of block weight is modified:
>> all witness data, including both scriptSig (used by pre-segwit inputs)
and
>> segwit witness data, is measured as 1 weight-unit (WU), while all other
>> data
>> in the block is measured as 4 WU.
>>
>> The witness commitment in the generation transaction is no longer
>> required,
>> and instead the txid merkle root in the block header is replaced with a
>> hash
>> of:
>>
>> 1. The witness reserved value.
>> 2. The witness merkle root hash.
>> 3. The transaction ID merkle root hash.
>>
>> The maximum size of a transaction stripped of witness data is limited to
1
>> MB.
>>
>> ===Deployment===
>>
>> This BIP is deployed by flag day, in the block where the median-past time
>> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).
>>
>> It is assumed that when this flag day has been reached, Segwit has been
>> activated via BIP141 and/or BIP148.
>>
>> ==Motivation==
>>
>> FIXME
>>
>> ==Rationale==
>>
>> FIXME
>>
>> ==Backwards compatibility==
>>
>> This is a hardfork, and as such not backward compatible.
>> It should not be deployed without consent of the entire Bitcoin
community.
>> Activation is scheduled for 18 months from the creation date of this BIP,
>> intended to give 6 months to establish consensus, and 12 months for
>> deployment.
>>
>> ==Reference implementation==
>>
>> FIXME
>>
>>
>>
>> _______________________________________________
>> 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/20170530/060fafbb/attachment.html>

2023-06-07 18:01:23

- reply

📅 Original date posted:2017-05-26
📝 Original message:Just to clarify one thing, what I described differs from BIP91 in that
there's no orphaning. Just when Segwit2MB support reaches 80%, those 80%
join everyone else in signaling for BIP141. BIP91 orphaning is an optional
addition but my guess is it wouldn't be needed.
On May 26, 2017 4:02 PM, "Matt Corallo" <lf-lists at mattcorallo.com> wrote:
> Your proposal seems to be simply BIP 91 tied to the
> as-yet-entirely-undefined hard fork Barry et al proposed.
>
> Using James' BIP 91 instead of the Barry-bit-4/5/whatever proposal, as
> you propose, would make the deployment on the incredibly short timeline
> Barry et al proposed slightly more realistic, though I would expect to
> see hard fork code readily available and well-tested at this point in
> order to meet that timeline.
>
> Ultimately, due to their aggressive timeline, the Barry et al proposal
> is incredibly unlikely to meet the requirements of a
> multi-billion-dollar system, and continued research into meeting the
> spirit, not the text, of their agreement seems warranted.
>
> Matt
>
> On 05/26/17 17:47, Jacob Eliosoff via bitcoin-dev wrote:
> > Forgive me if this is a dumb question. Suppose that rather than
> > directly activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in
> > just triggered BIP141 signaling (plus later HF). Would that avoid
> > incompatibility with existing BIP141 nodes, and get segwit activated
> > sooner? Eg:
> >
> > - Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support
> > for "segwit now, HF (TBD) at scheduled date (Nov 23?)"
> > - If bit 4 support reaches 80%, it locks in two things: the scheduled HF
> > (conditional on segwit), and *immediately* turning on bit 1 (BIP141
> support)
> >
> > I realize this would still leave problems like the aggressive HF
> > schedule, possible chain split at the HF date between Segwit2MB nodes
> > and any remaining BIP141 nodes, etc. My focus here is how
> > incompatibility with existing nodes could be minimized.
> >
> > (BIP91 could also be used if BIP141 support still fell short of 95%.
> > But if Segwit2MB support reaches 80%, it seems likely that an additional
> > 15% will support BIP141-without-HF.)
> >
> >
> > _______________________________________________
> > 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/20170526/b8000d3a/attachment.html>

2023-06-07 18:01:23

- reply

📅 Original date posted:2017-05-26
📝 Original message:Forgive me if this is a dumb question. Suppose that rather than directly
activating segwit, the Silbert/NYC Segwit2MB proposal's lock-in just
triggered BIP141 signaling (plus later HF). Would that avoid
incompatibility with existing BIP141 nodes, and get segwit activated
sooner? Eg:
- Bit 4 (or bit 5 or whatever, now that BIP91 uses 4) signals support for
"segwit now, HF (TBD) at scheduled date (Nov 23?)"
- If bit 4 support reaches 80%, it locks in two things: the scheduled HF
(conditional on segwit), and *immediately* turning on bit 1 (BIP141 support)
I realize this would still leave problems like the aggressive HF schedule,
possible chain split at the HF date between Segwit2MB nodes and any
remaining BIP141 nodes, etc. My focus here is how incompatibility with
existing nodes could be minimized.
(BIP91 could also be used if BIP141 support still fell short of 95%. But
if Segwit2MB support reaches 80%, it seems likely that an additional 15%
will support BIP141-without-HF.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170526/d6a31f4d/attachment.html>