On Fri, Feb 13, 2015 at 11:09 PM, Eric Voskuil <eric@???> wrote:
> On 02/13/2015 01:07 PM, Jorge Timón wrote:
>> On Tue, Feb 3, 2015 at 4:32 AM, Eric Voskuil <eric@???> wrote:
>>>>> For an alternative consensus to arise in this likely future scenario,
>>>>> the "unknown" miners need to be able to form their own consensus. This
>>>>> requires credible alternative implementations and maintainers with
>>>>> experience to support them and help drive towards agreement.
>>>>>
>>>>> As we see presently, for an implementation to be credible it needs to be
>>>>> in-use. That can take a long time to develop, but ultimately it brings
>>>>> more people to the table to guide such choices, and may even help to
>>>>> forestall significant conflict down the road.
>>>>
>>>> Remember, no majority of miners can force users to accept hardfork
>>>> changes to the consensus rules.
>>>
>>> That statement doesn't make sense. If no majority can do it, then it
>>> can't be done. You seem to believe that a hardfork requires universal
>>> acceptance. This is not the case.
>>
>> No majority of miners can force a hardfork. Majority of USERS.
>> Universal acceptance by users instead of just a majority?
>> I don't know, honestly. I think it should be something
>> uncontroversial that can be universally accepted (like getting rid of
>> obscure bdb-specific consensus rules, that was the last hardfork).
>> My point is that users decide the rules they're checking and miners
>> can't change that.
>> If 95% of the miners change the subsidy schedule to produce more than
>> 21 M but users reject this change, they will just listen to the
>> blocks produced by the honest 5%.
>
> This argument makes my point.

Well, I'm not sure what your point here was anymore, but my previous
statement did make sense.

>> Why this cannot happen with libsecp256k1 ?
>> I don't think you're answering to the question. In which way it is
>> more risky to depend on libconsensus than to depend on libsecp256k1?
>
> I did not say it could not happen with the crypto lib. I said it would
> not matter.

I agree, you would fork it, just like you would do with libconsensus.

> See previous comments about user base.

I don't think you have answered to this question anywhere.
If you did, I'm sorry, but I missed it.
Can you repeat it again? Please be as specific as possible (general
concerns about a specific foundation I don't belong to won't help me
understand).

>> Retesting without changing the code makes sense if some of your tests
>> are random.
>
> I didn't say it didn't make sense, I said the coverage would be comparable.

No, the coverage is bigger adding random tests, this can be very
useful as demonstrated by libsecp256k1 random testing.

>>> Furthermore, given that we're talking about randomly changing random
>>> tests over a practically infinite space, is practically zero percent of
>>> the surface area.
>>
>> What? The more random tests you run the more surface of that
>> practically infinite space you cover.
>> This seems obvious to me.
>
> Each time you change the code you start over. Coverage on old code says
> nothing about coverage on new code.

I didn't make the assumption that the code is changed, you did.
You could also not change the tests and leave the random tests running
forever (or until one test fails).

>> It turned out that openSSL had a very specific bug that had been
>> there for years.
>
> Because of the practically infinite surface area it's possible that a
> near infinity of bugs remain.

Yes, it is also possible that the random tests never show you anything
interesting.
In this case, it is possible that random scripts are never executed
differently in libconsensus and libbitcoin. But if they do once, you
have the certainty that libbitcoin has a bug (given that libconsensus
is the specification of the consensus rules).

>> Ok, I finally see what you're saying. Separating libconsensus would
>> require code duplication since, for example, the script type will be
>> required to produce scripts to sign them.
>> That may actually a good reason to never separate libconsensus from
>> bitcoin core, or do so only as a sub-repository or something.
>
> Any argument that it should not be isolated from core is an argument for
> not incorporating it into another lib. Why would one expect other libs
> to accept deficiencies that core would not?

You're saying that Bitcoin core reusing libconsensus code directly
instead of via its c API is an argument against using libconsensus in
other bitcoin implementations.
I disagree and I don't understand why you reach that conlusion.
libconsensus only supports a small part of everything you need to
implement the bitcoin protocol, but that's not a deficiency, that's a
conscious design decision.
Reimplementing the p2p messages, for example, doesn't have consensus
failure fork risks.

>> So I think your complain is that libbitcoin will have some code
>> duplication from libconsensus.
>
> Not just some, a very significant portion.

Whatever, you're still able to avoid reimplementing the parts that are
more risky to reimplement (because you an get forked out of the
network if you do so).
You already have that code implemented so I don't see what the problem is.
You seem to be complaining about the fact that lbconsensus won't allow
you to delete more code from libbitcoin.

>> libconsensus will only have a c interface with simple functions.
>> So, no, a common type lib is not what libconsensus is about.
>> I don't think there's any way around this.
>
> There doesn't really need to be a way around it. Alternate
> implementations are a good thing.

Alternative implementations of the consensus checks are an unnecessary risk.
Innovation in alternative implementations happens in higher layers.


> I would really prefer to agree, as I think we are all working toward a
> better future. But as I see it there would eventually be little reason
> to maintain libbitcoin if we took this dependency.

I strongly disagree. libconsensus implements the p2p protocol,
storage, concurrency, creation and signing of transactions, innovative
features like coinjoin, etc.
libconsensus will never implement any of that: it's meant to be a
stateless check-only tiny lib with no features beyond the consensus
checks.

>>> Developing for end-users is different than developing for developers.
>>
>> Agreed. I'm not sure if you're implying that current libconsensus
>> design is for end-users...It is definitely intended to be used by developers.
>
> The Satoshi code was built for users, not developers. The consensus
> interface, as a developer API, suffers from that underlying approach.

Bitcoin core is for users, not developers. libconsensus is for
developers not users.
It is a dynamic library (.dll .so) with a C API, it doesn't even have
command line tools and of course it doesn't have a GUI.

libconsensus != Bitcoin core (satoshi code)
libconsensus != libbitcoin

> e
>