<unnamed>

Public Key

npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8d

Profile Code

nprofile1qqsdlsacv2gdjc4h9ys4xmm78dnvqd6zhpdtey2yg75s2p7vyllc5jcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dssvvqrl

Publishing to

relay.nostr.net

nos.lol

relay.damus.io

Last Notes

2023-06-07 23:11:32 UTC

- 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 UTC

- 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 UTC

- 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:37 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:03:28 UTC

- 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:27 UTC

- 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:38 UTC

- 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 UTC

- 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 UTC

- 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>