Re: [bitcoin-dev] BIP149 timeout-- why so far in the future?

[Ryan Grant via bitcoin-dev]

Is there any reason that BIP149 activation on November 16th would
cause a problem?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] The BIP148 chain split may be inevitable

[Jacob Eliosoff via bitcoin-dev]

Just a quick follow-up on BIP91's prospects of avoiding a BIP148 chain
split, because I may have left an overly pessimistic impression -

In short: the timing isn't as dire as I suggested, BUT unless concrete
progress on a plan starts taking shape, esp miner support, *the split is
indeed coming.*

THE GOOD NEWS: several refinements have been noted which could get BIP91
(or splitprotection, Segwit2x, etc) deployed faster:
- The lock-in window could be shortened, eg to splitprotection's 504 blocks
(3.5 days)
- Of course the 80% threshold could just be reduced, eg to
splitprotection's 65%
- BIP91 nodes could start signaling on bit 1 the moment bit 4 reaches
lock-in, rather than waiting another period until it  "activates".
 (Orphaning of non-bit-1-signaling blocks would probably also have to start
at or shortly after the same time [1].)

Combining these approaches, *July 26* is an approximate hard deadline for
>50% of miners to be running BIP91 in order to prevent the split.  So,
significantly less tight than my previous June 30 (or my original,
erroneous "a few days ago").

THE BAD NEWS: no one should underestimate the steps that would need to be
completed by that deadline:
1. Coordinate on a solution (BIP91, splitprotection, Segwit2x, BIP148
itself, ...)
2. Implement and test it
3. Convince >50% of miners to run it [2]
4. Miners upgrade to the new software and begin signaling

In particular, #3: afaict a lot of convincing is still needed before miner
support for any of these reaches anything like 50%.  (With the exception of
Segwit2x, but it has the additional handicap that it probably needs to
include deployable hard fork code, obviously ambitious in 1.5 months.)


[1] See Saicere's comment:
https://github.com/btc1/bitcoin/pull/11#discussion_r121086886, and related
discussion at https://github.com/btc1/bitcoin/pull/11#issuecomment-307330011
.

[2] Note that >50% need to run the *solution*, eg BIP91; old BIP141 nodes
signaling segwit support do *not* count, since they won't orphan non-bit-1
blocks.  The impending split isn't between nodes that support segwit vs
don't, but between those that reject non-segwit-supporting blocks vs don't.


On Fri, Jun 9, 2017 at 1:23 AM, Jacob Eliosoff 
wrote:

> Ah, two corrections:
> 1. I meant to include an option c): of course >50% of hashpower running
> BIP148 by Aug 1 avoids a split.
> 2. More seriously, I misrepresented BIP148's logic: it doesn't require
> segwit *activation*, just orphans non-segwit-*signaling* (bit 1) blocks
> from Aug 1.
>
> I believe that means 80% of hashrate would need to be running BIP91
> (signaling bit 4) by ~June 30 (so BIP91 locks in ~July 13, activates ~July
> 27), not "a few days ago" as I claimed.  So, tight timing, but not
> impossible.
>
> Sorry about the errors.
>
>
> On Fri, Jun 9, 2017 at 12:40 AM, Jacob Eliosoff 
> wrote:
>
>> I've been trying to work out the expected interaction between James
>> Hilliard's BIP91 [1] (or splitprotection [2], or Segwit2x [3], which both
>> use variants of BIP91 activation) and the BIP148 UASF [4].  Some of this is
>> subtle so CORRECTIONS WELCOME, but my conclusions are:
>> 1. It's extremely unlikely BIP91-type logic can activate segwit in time
>> to avoid a BIP148 chain split.
>> 2. So, in practice all we can do is ensure the BIP148 split is as
>> painless as possible.
>>
>> REASONING:  First, some dates.  BIP148, whose deadline is already
>> deployed and thus unlikely to be postponed, starts orphaning non-segwit
>> blocks on midnight (GMT) the morning of August 1.  Meanwhile, here are
>> Bitcoin's rough expected next four difficulty adjustment dates (they could
>> vary by ~1-3 days depending on block times, but it's unlikely to matter
>> here):
>> 1. June 17
>> 2. June 30
>> 3. July 13
>> 4. July 27
>>
>> If Segwit activates on adj date #5 or later (August), it will be too late
>> to avoid BIP148's split, which will have occurred the moment August began.
>> So, working backwards, and assuming we want compatibility with old BIP141
>> nodes:
>>
>> - Segwit MUST activate by adj #4 (~July 27)
>> - Therefore segwit MUST be locked in by adj #3 (~July 13: this is
>> inflexible, since this logic is in already-deployed BIP141 nodes)
>> - Therefore, I *think* >50% of hashpower needs to be BIP91 miners,
>> signaling bit 1 and orphaning non-BIP91 (ie, BIP91's bit 4 must activate),
>> by adj #2 (June 30)?
>> - Therefore, as currently designed, BIP91 bit 4 must be locked in by adj
>> #1 (June 17)
>> - Therefore, >=80% of hashrate must start signaling BIP91's bit 4 by a
>> few days ago...
>>
>> There are ways parts of this could be sped up, eg, James' "rolling
>> 100-block lock-in periods" [5], to get BIP91 signaling bit 1 sooner.  But
>> to be compatible with old BIP141 nodes, >50% of hashrate must be activated
>> BIP91 miners by ~June 30: there's no fudging that.
>>
>> So, it seems to me that to avoid the BIP148 split, one of two things
>> would have to 

[bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc via bitcoin-dev]

Hi everyone,

It has been 3 weeks -- responses so far have been really helpful. People
jumped right in, and identified unfinished or missing parts much faster
than I thought they would (ie, ~two days). Very impressive.

Currently, we are working on the sidechain side of blind merged mining.
As you know, most of the Bitcoin cryptosystem is about finding the
longest chain, and displaying information about this chain. CryptAxe is
editing the sidechain code to handle reorganizations in a new way (an
even bigger departure than Namecoin's, imho).

I believe that I have responded to all the on-list objections that were
raised. I will 1st summarize the on-list objections, and 2nd summarize
the off-list discussion (focusing on three key themes).


On-List Objection Summary
---

In general, they were:

* Peter complained about the resources required for the BMM 'crisis
audit', I pointed out that it is actually optional (and, therefore,
free), and that it doesn't affect miners relative to each other, and
that it can be done in an ultra-cheap semi-trusted way with high
reliability.
* Peter also asked about miner incentives, I replied that it is profit
maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
is always positive.
* ZmnSCPxj asked a long series of clarifying questions, and I responded.
* Tier Nolan complained about my equivocation of the "Bitcoin: no block
subsidy" case and the "sidechain" case. He cites the asymmetry I point
out below (in #2). I replied, and I give an answer below.
* ZmnSCPxj pointed out an error in our OP Code (that we will fix).
* ZmnSCPxj also asked a number of new questions, I responded. Then he
responded again, in general he seemed to raise many of the points
addressed in #1 (below).
* ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
that if 51% can reorg, they can also filter out the reorg proof. We are
at their mercy in all cases (for better or worse).
* ZmnSCPxj also brought up the fact that a block size limit is necessary
for a fee market, I pointed out that this limit does not need to be
imposed on miners by nodes...miners would be willing-and-able to
self-impose such a limit, as it maximizes their revenues.
* ZmnSCPxj also protested the need to soft fork in each individual
sidechain, I pointed out my strong disagreement ("Unrestrained smart
contract execution will be the death of most of the interesting
applications...[could] destabilize Bitcoin itself") and introduced my
prion metaphor.
* ZmnSCPxj and Tier Nolan both identified the problem solved by our
'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
coded it at the time, but there is code for it now [1]. Tier proposed a
rachet design, but I think ours is better (Tier did not find ours at
all, because it is buried in obscure notes, because I didn't think
anyone would make it this far so quickly).
* Tier also advised us on how to fix the problem that ZmnSCPxj had
identified with our NOP earlier.
* Tier also had a number of suggestions about the real-time negotiation
of the OP Bribe amount between nodes and miners. I'm afraid I mostly
ignored these for now, as we aren't there yet.
* Peter complained that ACKing the sidechain could be exploited for
political reasons, and I responded that in such a case, miners are free
to simply avoid ACKing, or to acquiesce to political pressure. Neither
affect the mainchain.
* Peter complained that sidechains might provide some miners with the
opportunity to create a pretext to kick other miners off the network. I
replied that it would not, and I also brought up the fact that my
Bitcoin security model was indifferent to which people happened to be
mining at any given time. I continue to believe that "mining
centralization" does not have a useful definition.
* Peter questioned whether or not sidechains would be useful. I stated
my belief that they would be useful, and linked to my site
(drivechain.info/projects) which contains a number of sidechain
use-cases, and cited my personal anecdotal experiences.
* Peter wanted to involve miners "as little as possible", I pointed out
that I felt that I had indeed done this minimization. My view is that
Peter felt erroneously that it was possible to involve miners less,
because he neglected [1] that a 51% miner group is already involved
maximally, as they can create most messages and filter any message, and
[2] that there are cases where we need miners to filter out harmful
interactions among multiple chains (just as they filter out harmful
interactions among multiple txns [ie, "double spends"]). Peter has not
yet responded to this rebuttal.
* Peter also suggested client-side validation as "safer", and I pointed
out that sidechains+BMM _is_ client-side validation. I asked Peter for
CS-V code, so that we can compare the safety and other features.
* Sergio reminded us of his version of drivechain. Sergio and I disagree
over the emphasis on frequency/speed of withdrawals. Also 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc via bitcoin-dev]

Hi Sergio / everyone,

As some of you may know, Sergio and I each did an implementation of
drivechain. I started working on mine, and he started working on his,
and then I didn't hear from him for awhile about what he was doing.

Anyways, with two versions, we each have an opportunity to double-check
our work. For example, this already happened wrt the "ACK size". Let me
share from his linked BIP:

"By allowing miners to refer to transaction candidates by
transaction id prefixes, the space consumption for a single ack can be
as low as 2 bytes."

Sergio shared this with me last October at Scaling Milan. After
listening to him, we saw an opportunity to improve our design: now, our
miners can conjecture that miners will grant ACKs in a few simple ways
[always honest, honest+ignore some, ignore all], and it will precompute
these possibilities (guessing what rival miners will do, even before
they find and broadcast a new block). Therefore, in all honest cases,
our ACK-counting now requires zero (0) bytes to be sent over the
network. In dishonest cases it requires only a few bits per sidechain,
because we also maintain a deterministically ordered list, both of
sidechains and withdrawal attempts -- therefore it can just be a string
of binary information. This is not part of consensus, and so can be
further improved over time.

I'm sure there are still a few opportunities for mutual improvements
going forward.

In general, Sergio and I disagree over the withdrawal-frequency. a major
difference of opinion is over the withdrawal-frequency. I view
infrequent withdrawal as essential to the security model, but Sergio
does not. In both our designs, the withdrawal-time is configurable, but
Sergio's design seems to be optimized for cases with frequent withdrawal
attempts, whereas mine is optimized for cases with very infrequent
withdrawal attempts.

Another difference is that, as a direct result of earlier peer review, I
have been integrating 'blind merged mining' into my version. It may be
easy for Sergio to add BMM to his version, or it may not.

It is true that I am not interested in the hybrid model. I would not
make use of the multisig / centralized part, and so for me it
complicates the security properties for no benefit. I see why some
people are interested in it, though.

Paul



On 6/9/2017 5:54 PM, Sergio Demian Lerner wrote:
> I'm a bit late to this party. I just want to add that there exists an
> hybrid model where both a federation and the miners provide acknowledges
> (sometimes known as "votes" in drivechain terms and "multi-signatures"
> in a federation) of the sidechain state.
> 
> My Drivechain proposal (Feb 2016) was tailored to enable this particular
> use-case, which I'm not sure Paul's proposal enable.
> 
> 
> The proposal is on this list under the following subject: Drivechain
> proposal using OP_COUNT_ACKS
> 
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
> 
> 
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> 
> 
> In this proposal, the "poll" time is sidechain-configurable, and I
> proposed a few days delay was enough. 
> Some have said that a longer times are needed, such as 2 months.  
> So if you want to have a 2 month dalay for sidechain->mainchain
> transfers in this code, you still can. However a better dynamic cache of
> acks/nacks would be needed. However, for the hybrid use-case, one day is
> more than enough.
> 
> Regards
> 
> 
> 
> 
> On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev
>  > wrote:
> 
> Hi Peter,
> 
> Responses below.
> 
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> >> Surprisingly, this requirement (or, more precisely, this incentive) 
> does
> >> not effect miners relative to each other. The incentive to upgrade is 
> only
> >> for the purpose of preventing a "theft" -- defined as: an improper
> >> withdrawal from a sidechain. It is not about miner revenues or the 
> ability
> >> to mine generally (or conduct BMM specifically). The costs of such a 
> theft
> >> (decrease in market price, decrease in future transaction fee levels) 
> would
> >> be shared collectively by all future miners. Therefore, it would have 
> no
> >> effect on miners relative to each other.
> >
> > That's not at all true. If I'm a miner with a better capability than 
> another
> > miner to prevent that theft, I have reasons to induce it to happen to 
> give me
> > political cover to pushing that other miner off the network.
> 
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the