> On Jun 15, 2017, at 5:08 PM, Eric Voskuil <eric@???> wrote:
>
>
>>>> On Jun 15, 2017, at 10:08 AM, Jorge Timón <jtimon@???> wrote:
>>>>
>>>> On Tue, Jun 13, 2017 at 6:05 PM, Eric Voskuil <eric@???> wrote:
>>>>
>>>> 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.
>>
>> Please don't hesitate in requesting review for bip113 (easy one) and
>> bip68/bip112 (I love maaku but I think this should have been just one
>> BIP for clarity and because bip68 doesn't really make much sense
>> without bip112).
>> I understand that since you already have bip65, there isn't all that
>> much of a hurry to add relative locktimes, but I'm glad you have them
>> on your TODO list.
>>
>> I'm specially curious about your implementation of bip9, I reviewed
>> codeshark and rusty implementations for bitcoin core, then did my own,
>> and then reviewed sipa's implementation that finally made it. But the
>> different options we're mainly about how to fit it in bitcoin core at
>> the various times. Since libbitcoin's implementation of bip34 wasn't
>> painful like bitcoin core's, there wasn't in performance gain in
>> bip90, I'm just curious about bip9's cache in bitcoin core, which you
>> may chose to implement somewhat differently (and although I think I'm
>> completely alone on this, I would like to optionally expose that cache
>> on libconsensus, if that ever gets finished or extendended beyond
>> scripts, which I would love).
>
> If Core maintains a cache as proposed by BIP9 the libbitcoin implementation will be very different, and I would recommend against maintaining any such cache in libconsensus. Certainly we could not use it.
>
> You can see the mechanism is use for BIP34/65/66 in the bc::chain::chain_state class. This class manages all chain state for block validation (and unconfirmed txs). It is not limited to version history, it also includes all timestamp and bits information required for validation (testnet or mainnet). In other words the optimization of never hitting the chain is comprehensive, not just for activations.
>
> The class provides static generation of a map of heights as a function of the given (i.e. next) block height and configured forks. The height map is used by the blockchain library's chain state populator to populate all state necessary to validate the block. This keeps all state transition awareness in the chain_state class, allowing all other classes (such as the populator) to be very dumb.
>
> A benefit of the design is that a next block's chain state can always be promoted from its patent block's chain state without ever hitting the store. Similarly the top block chain state is promotable for tx pool validation. So there is a single population for startup and for the fork point of any new potential branch.
>
> Height-based population from the store is extremely fast, since indexing by height is array-based: O(1), though one can validate the entire chain while hitting the store only on population of the genesis block state (which is typically the case).
>
> As you can see there is no cache necessary aside from the top block's chain state, which is very small - consisting of 4 byte bits, timestamps, versions, and since BIP90, one 256 bit hash.
>
> Promotion is not only very fast, but the cache is constant-sized. It is a scalability goal of libbitcoin to never introduce costs that are not constant time in the size of the chain, apart from storage of the chain. This results in the size of the chain being largely irrelevant, apart from the cheapest resource (disk).
>
> BIP9/8 will extend the chain_state class and its tests only. It will not affect population, caching or anything else in the entire stack.
>
>>>> 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.
>>
>> summary again: I think you've done more than I would I have probably
>> done in your situation (I would have probably ignored bip90 for the
>> moment if there's no gain for my codebase at the moment) and I praise
>> you for that. Giving more responsible options to users in case they
>> are ever necessary it's always good.
>> no worries appreciated.
>>
>>>>>> 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.
>>
>> Yes, completely agreed, what by tradition is often called "standard",
>> it's really just "policy", which each node (including miners) can set
>> independently without breaking from consensus. Policys/standardness
>> rules should never be interpreted as consenusus rules no matter how
>> many nodes apply them (because they don't apply to consider blocks
>> invalid).
>>
>> I guess I used the wrong words. My point is...what if a a block
>> containing a bip113-invalid maliciously created
>
> You should avoid terms such as "malicious". There is no way for the chain to interpret or even define such concepts. They serve only to cause people to lose objectivity, resulting in poor analysis.
>
> This particular scenario has happened on testnet, not out of malice (which I can judge since I know the people involved were not aware of what was happening initially) but normal operation of a mining node (built on libbitcoin) that didn't care about standardness. This resulted in deep forking and if the miner(s) had achieved 51% would have created a persistent split had soft fork activation been based on a flag date.
>
>> to move the hashrate
>> majority over "legacy bitcoin" (which includes libbitcoin currently,
>> but will exclude it once it supports bip113 activation via bip9) to
>> separate it (among many others potentially) from the "new" network
>> validating bip113 (that's, I think, currently a very big network, one
>> can be never sure about its totality without violations).
>>
>> Let's hope that 51% of the miners think of such a stupid idea, but if
>> they did, what do you think libbitcoin should do?
>
> The fact remains that with less than 51% a split will occur unless 100% of the economy enforces the soft fork. In any case where there is less than 51% hash rate support this result is guaranteed, since, at a minimum, all miner rewards on the stronger chain constitute user money (more on this below) until spent, and coinbases have a spend maturation period.
>
>> a) maintain current policy and accept the division, even if at some
>> point you plan to activate bip113 too as a easy and good improvement,
>> somehow you prefer a different height than those who activate it
>> before you and never intended to fork from you.
>>
>> b) use the equivalent of invalidateblock in bitcoin core to protect
>> against a youre-not-ready-to-bip113-fuck-you-buy-your-own-miners chain
>> until you implement and validate bip113 to unify with the other chain
>> you wanted to be on.
>>
>> c) allow bip113-violating txs forever in libbitcoin
>>
>> d) I don't know, but I'm sure there's more options, even if absurd
>> like some of these
>
> I personally will implement the strong chain active forks, default them to enabled, and let node operators decide. As I pointed out earlier, delay in active soft fork implementation is unfortunate, but given current low penetration of libbitcoin nodes is not as significant an issue as it would be otherwise.
>
>>>> 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.
>>
>> Let's imagine bip149 is changed to 2020 for final bip8 activation of
>> bip141, miners can still signal it on any time in between and stop
>> validating or even violating on purpose the next block, versionbits
>> means no more support than a hardcoded height or timestamp. Just like
>> policy shouldn't be assumed to be consensus rules, miner signaling
>> doesn't guarantee node validation, sorry for the redundancy but only
>> node validation guarantees node validation.
>> This is the same for both bip113 in the example above and bip149 or
>> any other softfork deployed either like bip16 was, with bip34, with
>> bip9 or with bip8.
>
> This doesn't contradict what I have said. Miner signaling is not the issue. If majority hash rate is on the legacy chain the flag day soft fork activation will cause the economy to split along the line of who is validating the fork.

It isn't necessary to the argument above, but I need to correct my own error below. A fork-invalid block on legacy would not "prevent unification", that requires either majority hash rate or rejection of a block in the forked chain (a soft fork applied in legacy after the split). It would just cause the split. Given that 51% hash rate is presumed to be hostile to the fork it seems very likely that this would occur. This is really no different than the situation where 51% fails to signal SW in the case of BIP148 - the outcome is exactly the same.

> Furthermore the split will become irreconcilable (i.e. into the new fork) as soon as a fork-invalid block is accepted into the legacy chain, which nothing prevents. This is true with BIP148 and it is true with BIP8.
>
>>>> 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.
>>
>> Alright, I would like to help if possible in giving bip8 as an option
>> for libbitcoin users.
>
> You are welcome to do so. Given that BIP9 is active it should be built on that code, which should be merged first. I am traveling for 2 more weeks, but can assist as I am able, especially when I return home. I recommend applying a feature branch to the version3 (release) branch.
>
>>> 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.
>>
>> No, bip148 uasf inherently creates a chain split, bip149 uasf doesn't
>> create a split any more than bip16 or bip113 do.
>
> Flag day activation creates a split, which is why formerly it was generally considered a bad idea. BIP16 would definitely create a split if majority hash power was not enforcing it, following the scenario I described above. BIP148 and BIP8 activation are the same in this regard.
>
>> To reiterate: I feel bip148 is unfortunate and I haven't lost the hope
>> for sw supporters to abort in favor of much more secure bip149 IMO.
>
> I do t know what will happen, but if people want to split it is not for me judge.
>
>>>>> 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.
>>
>> If there's a subsidy and/or fees there will be pow to get the offered
>> reward, I hope we don't have to debate this.
>
> We don't have to debate it because it's simply a restatement of what I said above (somebody must/will mine).
>
> It however does not in any way refute what I said directly above. For people to control mining decisions people must mine. One cannot compel miners (even on a UASF) to mine certain txs over others.
>
> Assume there is just one miner controlling 51% hash rate (close to that now). If governments decides the miner can keep mining as long as it doesn't mine certain types of transactions, what will happen? The only way they get mined is if others, totaling at least 51%, willing and able to ignore the restriction, mine them anyway. Rewards alone will not overcome a regulatory constraint that amounts to a 100% tax on those rewards.
>
> At least 51% of the hash rate must be individuals for Bitcoin to survive, as there is zero chance of this scenario not playing out. What we are seeing now is a little taste of what is to come.
>
> The economy can always split to create the rule set they prefer, but it cannot ensure that the economic incentives of miners are aligned with those of the economy, and it cannot require miners to select any particular class of tx. A state for example operates under totally different economic assumptions than a free market, and large organizations are always subject to state controls.
>
>> This is not only true for bip148 but for any fork or altcoin.
>>
>>> 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).
>>
>> My point is not about 51% hashrate activating softforks nobody wants
>> (I agree, they can), it's about purposely violating new rules that aren't fully deployed yet,
>
> If rules aren't deployed to a large number of economic nodes, they are not rules. This is not a legislative committee process. The only thing that matters is participation in mining and in the economy.
>
>> but no user oppose to deploy.
>
> If they haven't deployed a hard fork they are effectively in opposition. If they haven't deployed a soft fork, they either do not care either way, or are opposed. That is the only measure that can be relevant.
>
>>> 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.
>>
>> I disagree. IMO users rule,
>
> It's not a matter of opinion. The economy controls what is invalid, only. Mining controls what transactions are selected (effective). These are independent. The economic and transactional controls are independent by design.
>
>> and specially those who accept btc for
>> wares or services. But we don't need to agree here I think.
>
> In the simplest of examples, the 51% miner can mine zero txs, can double spend, can enforce any set of non-fungibility controls, can block the use of any script feature, etc. the economy cannot prevent this. Miners can prevent it, and individuals can be miners. This is how the security model works.
>
>>> 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.
>>
>> I'm very aware that the fact that hashrate should likely follow reward
>> (subsidy + fees)
>
> Security is never about "should", it is always about "can".
>
>> and difficulty as it does in every altcoin had been abused with fallacies by bip148 supporters, including the false
>> equality of uasf == bip148, imo uasf is all about bip8 which is
>> intended to be permanent and not just "segwit/bigger blocks now!". It
>> may fail at being permanent just like bip9 did, but at least try it.
>>
>>
>>>> If there's a consensus change that benefits all users but miners don't
>>>> like,
>>>
>>> Miners are users, so this is a false premise.
>>
>> No, that's actually just a bad choice of words, let me rephrase:
>>
>> If there's a consensus change that benefits all users (other than
>> miners) but miners (which are technically also users) don't like...
>
> This implies that Bitcoin is not a fungible money. A miner becomes a hodler as soon as he earns any reward.
>
> It is also pointless to require a model in which the desires of all users (except miners) can be assumed. Unless those desires can be *known* it's irrelevant. And the only way desires can be expressed is via participation.
>
>>>> 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.
>>
>> I strongly disagree here. If you offer a reward for pow you'll tend to
>> get a hashrate "proportionally profitable" to your reward. There's
>> plenty of evidence with altcoins on this. Of course, the reward and
>> the difficulty themselves can be influenced by many other factors,
>> bip148 supporters seem to live in an spherical cow world where
>> everyone demands exactly what they do, because "game theory". I think
>> we established we agree on that, but let's not devolve this into a
>> "you'll have demand but the production won't arrive", please.
>
> Getting proportional hash rate has little to do with controlling the decisions of miners. See above.
>
>>> Furthermore, there is no rational basis to determine or even define the "best interests" of *all* users.
>>
>> This seems correct to me and beautifully moral neutral.
>> Anyone that pretends to be able to predict what "everybody will want"
>> is just being delusional to himself or straight lying.
>
> See above comments on excluding rewards earned by miners from the economy.
>
>> In my case I may be hopelessly delusional in thinking we can stay
>> together, even if we moved we moved bip113 activation to match bip149
>> (which is too late for since some nodes will never accept
>> bip-113-invalid after bip113 activated, even if you didn't supported
>> at that point, which wasn't a hurry unless 51% hashrate gets nuts
>> anti-bip113), would you still your validation of bip113 be conditional
>> to your "most work still valid for legacy nodes chain" policy?
>
> The policy isn't tied to "legacy nodes" it is tied to greatest work chain (which in Bitcoin defines what is money).
>
>> I hope you're fearing about the alternative which is actively giving
>> someone control over "anti-checkpoint" blocks that you'll simply not
>> follow in an emergency, but obviously you don't want emergencies in
>> your code long term, consistency is a must and I deeply respect that.
>> Ideally you don't want emergencies like 51% of the hashrate mining a
>> bip113-invalid chain,
>> but I think there would be little point since you could protect very fast.
>>
>> I see anti-bip149 miners just like I see anti-bip113 miners, stupid,
>> and I would hope that those blocks and coins are invalid to most
>> people, but I cannot force people to reject anti-bip113 coins. This is
>> free software, anybody is free to accept bip113-invalid coins, but who
>> wants that?
>> Extrapolating my reasoning from bip148 to bip149 contains at least 2
>> fallacies that I think I've counted. But please don't equate uasf to
>> fallacies because bip8 is I think an option to perdure.
>>
>>>>>> 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.
>>
>> Completely agree, that's why I always prefer not changing the rules
>> over doing it in a controversial way.
>
> If even one person is robbed, it's still a robbery.
>
> Bitcoin therefore is designed to resist change, not just to give the power of change to a majority, or plurality. This is its primary security feature. It requires that people leave the money if they want a different money. This can result in many monies (and has) and is no different than people freely choosing silver over gold, etc. that is not a change to the money, it's a new money.
>
> Bitcoin, like any money, derives its value from the size and scope of its network (things you can buy). The larger the network, the harder it becomes for a new money to take hold. It was much easier for Satoshi to create new monies and bring people with him, and even later, but it will continue to get harder as the network grows.
>
> People decry the lack of "leadership" in driving changes. This is a sign of success. Over time the various alt and splinter coins will be overcome by the network effect of the largest and disappear into irrelevance. This also means it will have become nearly impossible to create an effective competitor to the network.
>
>> If you want to change the rules without causing a split you need to
>> convince "everyone" to accept your rule changes as something good.
>> Otherwise it's just a matter of time before some/all users opt-out of
>> the changes they don't like,
>
> No need to put "everyone" in scare quotes, everyone is correct in the literal sense.
>
>>>> I think some changes need to be resisted and others not.
>>>
>>> This is a purely political argument. Who decides if not everyone?
>>
>> Agreed on the first part, everyone is just really "each one" for the
>> second, it's either full agreement or fork by a dissenting minority,
>> in their full right to do what they want as free software users.
>
> Yes
>
>> What
>> I'm suggesting is discriminating miners from the "users" group
>> consensus changes should serve to.
>
> Should is irrelevant, as this is not possible (nor is it desirable). Miners are miners when they mine and part of the economy when their money becomes spendable. As a fungible and anonymous money these are strictly independent roles.
>
>> I think that's the whole point of uasf: non-miner users resist from
>> miner-users having veto power on consensus changes, even if they're in
>> the best position to help to most for changes everybody wants
>
> Creating your own coin is always an option, but this does not give the economy control over mining, it only ensures that a subset of previously valid transactions are invalid in the new coin. It must be a new coin because unchanged nodes reject it (lower hash rate chain). In this sense it has the same behavior as a hard fork (older nodes don't follow). This is true of any soft fork activation that is not a consequence of greater work (e.g. flag day).
>
>>>>>> 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.
>>
>> Yes, please, let's explain things as they are, to reiterate, bip148 is
>> wrong IMO.
>>
>>>> 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.
>>
>> While discussing with bip148 supporters, I assured that august 1 was
>> unacceptable for libbitcoin but maybe some tbd date for bip149 would
>> do it.
>> I lied without knowing: if you oppose bip8 there's no date for you to
>> accept bip149
>
> Again, it is not opposition. But if a change does not have majority hash power then it is fundamentally an altcoin (see above) and we have a policy of not dedicating resources to altcoins (not opposing them). BIP8 can cause activation under majority hash rate and of course if that happens we would implement it. Otherwise it's a failed activation from that perspective.
>
>>>>>> 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.
>>
>> incorrect, bip8 doesn't assume anything about the economy. It may
>> result in a split or not depending on the concrete change and if
>> anybody resists it (unlike bip148, this one will cause a split as a
>> certainty).
>> BIP148 will produce a split, and then, if there's a hashrate majority,
>> a unification, again, not so different from bip113
>
> I was not referring to the consequences but the flawed underlying assumption. The same flawed argument is often applied to PoW change as evidence that the economy can control 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 this means libbitcoin it's going to implement bip8 and later
>> bip149, I'm very happy.
>
> My plan is to follow the simple and objective policy we have in place as a way to conserve resources and to stay with the dominant network over time and to avoid political maneuvering.
>
>>>> 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.
>>
>> yeah, bip148 can not only fail in reunifying the 2 chains but even in
>> activating sw. BIP149 cannot fail on the latter,
>> only on the former if
>> it doesn't get enough hashrate before nov15, no matter how much they
>> need, I think it defeats the whole point of uasf.
>> But you are wrong in the part that "legacy-chain" won't follow
>> bip148-chain if the latter gets 51% hashrate, for bip148 blocks are
>> also valid for "legacy" nodes.
>
> Any split can result in a unification failure. When a split gets long it is in the economic interest of both sides to prevent a reorg into the other, and both can easily do so.
>
>>>> 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.
>>
>> I have no intend to promote bip8 with disinformation like it's being
>> done with bip148, But please don't close yourself to other uasf that
>> aren't bip148 like bip8 and bip149.
>
> If they eventually get majority hash rate then they fall under our policy of implementation, if they never do so then they remain a weak branch. Chasing weak branches has no end to it. There is an unlimited number of such scenarios and deciding among them is political in nature, not objective.
>
>>> Thanks for thinking of and supporting other implementations. Optional libconsensus has worked out well for us.
>>
>> Yeah, thanks for being always open to feedback even if I sometimes I
>> make dumb assumptions about your codebase.
>
> NP, it's one of the reasons I rarely comment on the Core codebase.
>
>> Even though libbitcoin isn't using the libconsensus API as it is and
>> is respecfully chosing to remove layers it doesn't need,
>
> Yea, the factoring of the library isn't great. I realize that's not your issue, but the important aspect is that we offer the source files with full integration and unchanged.
>
>> I do consider
>> libbitcoin one successful user of libconsensus, I just wish that the
>> library offered more. You can help simply by saying what would you
>> want next in libconsensus.
>> Offering non-libconsensus options shouldn't be a problem but he
>> contrary, at the very least another chance to test libconsensus on top
>> of real users that just want more options than usual. More users,
>> good.
>
> The only thing I would like to see is a full factoring from Core. But the compiler does removed unused functions so it's not terrible. I could be wrong, but I don't think moving past script validation is going to be feasible as a general purpose independent validation library.
>
> e
>
>>> 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
>>>>>>>