> On Jun 12, 2017, at 11:54 PM, Jorge Timón <jtimon@???> wrote:
>
> Oh, since you said you implemented activated softforks I assumed you
> already had bip9, which was used to activate csv (bip68/bip112) with
> bip113 (median time improvement).
> It seems you weren't aware those were active already, but they did in
> 2016, see http://bitcoin.sipa.be/ver9-ever.png

You are right, I wasn't aware. As you can see I don't spend a lot of time working on protocol changes :). I'll add this to the backlog and get it backported to v3.

> Regarding buried deployments, I think the reorg is relevant, since you
> claim it is not an optimization or simplification in libbitcoin as it
> was in bitcoin core, you could just have ignored that bip unless you
> are worried of such a long reorg ever happens (having code different
> from core there shouldn't be a problem unless there's that reorg).

Correctness is important, and as I mentioned, it is important to our independence that independent soft forks can be selectively applied.

> But anyway, that topic is unrelated, I just wanted to thank you for implementing it for extra compatibility even if you had no need for it.

No worries. More below.

> On Mon, Jun 12, 2017 at 3:06 PM, Eric Voskuil <eric@???> wrote:
>>> 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.
>
> I see, good.
>
>>> 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.
>
> It seems we mostly agree on bip148
>
>>> 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.
>
> No, that isn't true, it is a certainty that bip148 without 51%
> hashrate will create a split with previous nodes, but bip149 won't
> produce a split unless miners very actively produce it.
> Let's take bip16, for example, which also activated with a fixed datetime.
> Even if it had activated without 51% hashrate validating it, it
> doesn't wouldn't have necessarily produce a split. Old miners wouldn't
> had in principle included non standard txs with the new format, so
> their blocks would be valid for both old and new nodes.
> For miners to produce a split, they would have to mine a block with an
> invalid bip16 tx on purpose, and 51% of the hashrate mining on top of
> that block.

Standardness is not part of consensus. I find problematic the reliance on standardness to rationalize certain forking behaviors as "safe". Libbitcoin for example does not enforce most of Core's standardness rules, specifically the ones that are hygienic as opposed to DoS aversion.

So it is very much true. As a matter of consensus, greater than 50% hash rate is required to prevent one's node from eventually splitting from the network following enforcement of a soft fork at that node. The hope that the entire original network will mine only "standard" txs which are presumed to not violate the new rules does not prevent the split.

> With bip149 is the same, even libbitcoin doesn't validate bip141
> (segwit) when it's active via bip149 due to the final date instead of
> 95% hashrate signaling it, libbitcoin users won't be forked off bip149
> users unless 51% of the hashrate support a chain with an invalid
> segwit tx in it.

If 51% of the hash rate does not enforce SW a miner can effectively include a SW-invalid tx. This will result in libbitcoin and other non-forking nodes, properly accepting it as valid, remaining on the strong chain while the weak SW-enforcing chain splits off. This would be the case regardless of policy enforcement. Miners are not obligated to enforce policy and often mine policy-violating txs or have differing policies.

> But if you are against bip149 at any date, it seems you are just
> against uasf in general. Then it seems we disagree there.
> I'm in favor of uasf if done properly (and I think the proper way is
> using bip8).

This is not the case. I am not for or against any forks. People can apply whatever rules they want. They just create a new consensus (set of people using a given coin) in doing so. I am against people who should know better misleading other people into believing certain things are safer than they actually are.

A UASF inherently creates a chain split. The only reason for such a technique to be attempted is if there is less than majority miner support. A majority of hash rate can apply a soft fork safely at any time. I'm against misleading people, not against creation of new coins.

>> 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.
>
> That would be ideal, also to improve censorship resistance.
> But users don't need to become miners only to change the rules in the
> ways they want, to do that they only need to change the rules they
> validate on their own nodes (and coordinate with other users,
> obviously).

This is not true. Someone still must mine, regardless of the rules. Majority hash rate will always control tx selection (as you agree and refer to as censorship). And "bad" miners cannot be replaced with "good" miners through rule changes. Miners can enforce whatever soft forks they desire, including invalidation of all SW txs on the BIP148 branch for example, or all anonymous txs on any chain (which is inevitable if mining remains centralized).

There are two orthogonal security models in Bitcoin - mining and economy. Neither controls the other and both must be decentralized. The economy controls hard forking and miners control soft forking. The consequence of centralization of either is that a small group (such as a state) *is* the consensus and everyone that uses their money trusts them.

Mining centralization cannot be ignored, and the only resolution is for individuals to mine (which is essentially tautological). Unfortunately there are some who persist in promoting the idea that mining is a service under the control of the economy, and this is just not the case. Telling people that the economy controls mining is dangerous advice. And a PoW change does nothing at all to mitigate this, and actually increases centralization while also reducing security. Censorship resistance is not simply a nice-to-have feature, it is fundamental to Bitcoin's security model.

> If there's a consensus change that benefits all users but miners don't
> like,

Miners are users, so this is a false premise.

> we don't need to give the power to block it like bip9 does: we
> can use bip8 instead from now on, or at least while the hashrates
> proves to not have the best interests of users in mind, like I think
> it's the case with their blocking of bip141.

This is delusional. People who believe that the economy can control mining do not understand the Bitcoin security model. Furthermore, there is no rational basis to determine or even define the "best interests" of *all* users.

>>> 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.
>
> I don't think the goal of Bitcoin is to resist consensus changes. Why
> would it be the goal when the consensus changes don't harm any users and help some.

Bitcoin is a money. If a money changes in a way that is not entirely predictable at the time it is purchased or as later explicitly accepted by *all* owners, it is inherently a theft from some by others. The definition of Gold is *very* difficult to change. This is the primary aspect of hard money.

> I think some changes need to be resisted and others not.

This is a purely political argument. Who decides if not everyone?

>>> 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.
>
> Well, the opion is no date would satisfy you, you will remain against
> bip149 no matter the date, right?

I'm not against people enforcing any rules they desire. I'm for educating people so that maybe enough people will participate that Bitcoin can survive the inevitable state attacks that befall any attempt at hard money.

>>> 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.
>
> Well, I even lied, I said there would be one date for which libbitcoin
> could prepare for bip149, but that certainly preparing for bip148's
> august 1 was unrealistic.
> It seems that's not the case, so sorry, I will tell the person that I
> was wrong on that (even if that reinforces his point that a later date
> won't help with many people).

Sorry, not really following this.

>>> 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.
>
> There's many things that can happen if there's a split.

Agree, but UASF and BIP8 both produce this result as they both incorrectly assume that the economy controls mining.

>>> 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.
>
> I see, so you will only support bip8 activations if 51% the hashrate
> follows the chain in which the new rules are being validated, correct?

Sort of. I would only *implement* code under these conditions. It's up to our users to *enforce* the forks they desire from those that are implemented (via config). If I had the ability I would implement all soft forks and let people choose.

> If bip148 gets 51% there won't be split and the activation is valid
> for anyone using bip9 activation for bip141, even if you don't
> implement bip148 in your node.

That's a false assumption. A split can and likely will persist even if 148 eventually achieves 51% (see above past comments). If that does not happen then you are correct but only if activation occurs before the SW BIP9 timeout. So it might be a little messy.

> Thanks for the clarifications, although I cannot hide I'm disappointed
> that you reject uasf in general and not just bip148 specifically like
> me.

Again, I do not reject it, but I do reject misinformation, especially with respect to the safety of people's money, and invalid interpretations of the system security model.

Thanks for thinking of and supporting other implementations. Optional libconsensus has worked out well for us.

e

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