Hi Jorge,

> On Jun 12, 2017, at 7:11 AM, Jorge Timón <jtimon@???> wrote:
>
> I'm all in favor of uasf and I think it was a flaw in bip9 not to
> allow to unnecessarily give the hashrate majority the power to block
> consensus changes, bip8 solves this. The interest of the majority of
> the hashrate may not be economically interested in harmless
> improvements that benefit some user and don't harm any user (sorry, to
> reiterate).
>
> At al lights, It seems 95% of the hashrate isn't willing to valtidate
> and also signal the new consensus rules specified in bip141.
> Libbitcoin correctly implemented bip9 for csv according to the all the
> existing tests

I realize it's not your area of operation, but actually Libbitcoin does not include support for either BIP9 or BIP112 (CSV). This is in accordance with our policy on forks. All forks active on the strong branch of Bitcoin mainnet are implemented.

> and I think there's no reason libbitcoin wouldn't offer
> support for bip8 in future deployments.

If it was used to successfully activate a soft fork it would be implemented.

> Although I only vaguely know
> libbitcoin besides the layers betwen libsecp, I offer myself to adapt
> libbitcoin to bip8 from bip9, but I bet erik will find it quite easy
> to implement too

Much appreciated, though you are correct that I could do it relatively quickly. The full set of SW BIPs will take a little longer.

> I also know some other parts like "buried deployments", because I
> pushed for that and I discovered erik doesn't like it.

Yes, as we discussed in Milan. I realize you advocated for this as a simplification and performance optimization, but it actually created a lot of additional complexity without any material performance improvement.

> He ended up
> offering another option that doesn't make sense for libbitcoin's
> because as he explained there's no optimization or simplification
> here.

Right, when validating the entire chain libbitcoin never hits the store to obtain activation data. When validating the remainder of the chain after a restart it hits the store only for the first block. The fact that Core repeatedly hits the store (prior to BIP90) is an implementation decision, as I pointed it to others via bitcoin-dev, not a protocol concern.

Libbitcoin allows a user to observe/test/simulate the historical behavior of Bitcoin with any combination of forks and network protocol levels, by config changes only. BIP90 *added* another fork to the mix, it did not (could not) remove others. Each consensus change and network protocol change constitutes additional complexity unless one abandons past versions and requires that users apply all implemented forks.

> I just think if we get too a reorg as long as to get to "buried
> deployments" we're just f#$%ed or we weren't conservative when moving
> from whatever other deployment to "buried deployments". I enormously
> respect the consistency in the arguments despite the pow needed. I
> didn't expect it but I welcome it, that will be easy to maintain, so
> why not?

The unlikelihood of reorganization being deep enough to produce unintended behavior as the result of BIP90 is beside the point. BIP90 was added in v3 because it is active on mainnet. Now that it is implemented it is not hard to maintain, but it presents just one more thing for people to understand and preserve.

> But bip8's uasf it's only for future deplyments (including
> re-deployments like bip149), it doesn't apply to bip148.

Sure, and the fact that BIP9 may never activate any fork demonstrates the benefit of libbitcoin not implementing forks before they activate. I realize this means libbitcoin is not a force in moving forks forward and that any delay in implementation after activation is problematic for users. The former is not an objective of libbitcoin and the latter will be resolved as we mature.

> I think it would be irresponsible for libbitcoin to signal
> bip141/segwit without actually validating it.

Libbitcoin doesn't signal at all, as only miners signal and we do not currently create block templates. That will change in v4, at which point block version signaling is simply derived from what soft forks are enabled via config. As such you can see that there would be no built-in mechanism to signal a fork without validating it.

> Therefore bip148 is
> irresponsible for asking libbitcoin and all its users (and other
> implementations and users in similar situations, with their own
> software to maintain) to ask "ether you are with me in the next 2
> months or you are against me": that's clearly a false dilemma.

Libbitcoin users will be on the strong chain, along with all older and non-148 Core nodes and others. I agree that the idea of shaming people into purchasing into BIP148 (which is the only time validation would matter) is based on a false dichotomy as presented. People can still support SW and reject enforcement of it via the economic gambit of BIP148. More concerning is the false idea that buying into 140 Coin is the safest option for people. This is both self-serving and untrue. It is self-serving in that it asks other (presumably uninterested) people to risk their money in order for the gambit to succeed, while not honestly presenting the risk. The safest option is of course to hold below the fork.

> BIP149 is a uasf proposal based on the long-term-oriented bip8 (which
> just turn bip9 expiry_date into
> latest_possible_activation_date_despite_what_hashrate_says). Even
> though the final bip8 activation date for bip149 is to be deternined

Any soft fork that is enforced without majority hash power support will create a chain split. As I understand it that is what BIP8 will produce upon expiry absent such support. It's hard to see that as materially different than the situation produced by BIP148.

My personal opinion on the matter has been clearly stated on bitcoin-dev. If people want their say over miner decisions, they can get that say by mining. Unless individuals mine, mining will be centralized, and that is a serious problem for Bitcoin. Arguments that miners can be "fired" or otherwise controlled by the economy are nonsensical, individuals mining is the only way for individuals to control the decisions of miners.

> To be clear and summarize:
>
> 1) I assume "libbitcoin" (or the people involved) have no "opened
> complain" against bip141 (aka segwit)

I would agree.

> 2) BIP8 is an improvement over bip9 for future consensus rule changes,
> for it makes miners' signaling useless for veto.

If one is not concerned about chain-splitting then this is fine. Ultimately Bitcoin exists to resist change, and creating a new money is really the only way to change it. The question is always how much of the economy will join the new money.

> 3) There's a date for which "libbitcoin" wouldn't consider bip149
> rushed (even if the date it's in the air post nov 15)

I don't think libbitcoin would have any opinion on the matter.

> I've been using libbitcoin users as an example of people that could
> get hurt by bip148, but that hasn't dissuaded bip148 supporters.

Nothing will dissuade them, it's a political battle.

> They
> believe their coin will be more valuable and thus they will get 50%+
> hashrate in no time and thus the hashrate will follow and the split
> will be short-lived, which is a plausible scneario but not the only
> one. I fear bip148 are being delusionally optimistic, I wish I'm
> wrong.

You are correct that there is quite a bit of delusional thinking going on. It is. Dry likely that legacy users will block any unification (destruct of legacy money) by unilaterally enforcing what I call "mutual destruct" - a soft fork to reject the first 148 block. It is also likely legacy miners will act to preserve their rewards by signaling SW in the case where 148 starts to apply economic pressure, which could ultimately destroy 148 Coin value.

> If libbitcoin rejects bip149 I used this project as a wrong example,
> so please, let me know what you think about bip149, the last thing I
> want is putting worfs in someone else's mouth.

If it activates and has the greatest work it would be implemented as per our documented policy.

Best,

e
>
>> On Sun, Jun 11, 2017 at 7:28 PM, Eric Voskuil <eric@???> wrote:
>> The libbitcoin documented soft fork policy is that we implement soft forks
>> that are activated on the Bitcoin branch with the greatest work. Any person
>> can today "activate" segwit by merely applying a new rule to require SW,
>> which is essentially what BIP148 does. That doesn't however make it the
>> branch with the greatest work.
>>
>> If people choose to *consider* confirmations on a weak branch as sufficient
>> for payment (i.e. money) they of course have that power, but it is an
>> alternative money to Bitcoin and as such it is not my plan to dedicate
>> previous resources to it.
>>
>> This is not a statement for or against BIP148 or SW, it is just consistent
>> application of a policy that has been in effect for a long time and was
>> documented before BIP148 existed. The policy exists to preserve resources,
>> given the large number of proposed forks, and to objectively maintain
>> independence.
>>
>> I agree that SW can be implemented quickly in libbitcoin, and we have put in
>> place structure in v3 that makes it relatively straightforward. But it may
>> also come down to developer availability. However the project is FOSS and
>> anyone can issue a PR.
>>
>> e
>>
>> On Jun 11, 2017, at 6:25 PM, Juan Garavaglia <jg@???> wrote:
>>
>> I doubt SW will happen in Aug 1st.
>>
>> UASF looks more a menace than a real thing for me.
>>
>> If SW activate in Bitcoin with hard work I think can be implemented in 10-14
>> days in Libbticoin.
>>
>> SW is at least in theory a SF and libbitcoin nodes will not be affected in
>> any way, we performed extensive test in Bitcoin Testnet (SW activated) and
>> works safely.
>>
>> Regards
>>
>> Juan
>>
>>> On Sun, Jun 11, 2017 at 9:52 AM mlmikael <mlmikael@???> wrote:
>>>
>>> Hi Eric/libbitcoin ML!
>>>
>>> So SEGWIT kicks in on August 1:st and then likely SEGWIT will be the
>>> main chain.
>>>
>>> How is SEGWIT on LibBitcoin going?
>>>
>>> This is kind of important for LB to be functioning continuously through
>>> the transition no?
>>>
>>> There may be details I have missed one or other way, hope this thread
>>> can collect relevant clarifications.
>>>
>>> Mlmikael
>>> _______________________________________________
>>> Libbitcoin mailing list
>>> Libbitcoin@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>> --
>> Juan Garavaglia
>> +5491137616909
>>
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>
>>
>> _______________________________________________
>> Libbitcoin mailing list
>> Libbitcoin@???
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin
>>