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
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
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
order to organize in the scant few weeks remaining.
>
> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> If segwit is activated before Aug 1, as now seems likely, there will be no
> split that day. But
h >=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@lists.linuxfoundation.org> wrote:
>>
>> If segwit is activated before Aug 1, as now
uot; 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
> > co
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
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
t 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:
> > Forg
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" <
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
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
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.*
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
>
> 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
>
> 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
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
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
>
> 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
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
> 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](
21 matches
Mail list logo
