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.

>>>>> Please try to come up with an example of something that could go wrong
>>>>> with different bitcoin implementations sharing libconsensus code,
>>>>
>>>> It has already happened that a bug has been pushed out broadly,
>>>> requiring a temporary shut-down of the entire network. Imagine a
>>>> scenario where there are many disparate code bases. The impact of a
>>>> failure caused by any one of them is minimized.
>
> 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.

>>>>> it is very hard for me to argue about "decentralization" and "strength"
>>>>> in this abstract and vague way.
>>>>> Please explain to me in which ways libconsensus implies risks that
>>>>> libsecp256k1 doesn't, for the shake of your examples.
>>>>
>>>> The curve library implies the same technical risk, but is independent of
>>>> the political risk.
>>>
>>> There's no political risk on libbitcoin using libconsensus.
>>> libconsensus cannot be forced to upgrade so no new checks can be
>>> pushed onto libbitcoin.
>>> If, for example, libbitcoin wanted to implement a softfork change that
>>> the official distribution of libconsensus doesn't implement,
>>> libbitcoin can implement the additional checks outside of libconsensus
>>> (or just fork libconsensus).
>>> Seriously, I don't think there's any "political risk" in libconsensus.
>>
>> Your understanding of hardforks and lack if visibility into the source
>> of the leverage that the Foundation has with miners seems to be why you
>> are missing the larger issue.
>
> I believe I have a solid understanding hardforks and softforks so
> must be the other thing about the foundation, which honestly doesn't
> interest me much.
> Still, if an undesired change is introduced to libconsensus you can
> fork it, just like you would do if a backdoor was introduced in libsecp256k1.

See previous comments about user base.

>>>>>>> I would at least suggest to use libconsensus for testing
>>>>>>> your script interpreter implementation and your signatures checks.
>>>>>>
>>>>>> Consider for a moment what this implies. In order to run any such
>>>>>> testing we need test vectors to run through both implementations. There
>>>>>> is no other way to perform such testing, and notably there is no need
>>>>>> for shared code.
>>>>>
>>>>> Well, even running random bitstrings in both interpreters would be
>>>>> useful, as any difference in results would be a symptom of an
>>>>> extremely dangerous bug.
>>>>
>>>> Fuzzing is simply a means for generating test vectors.
>>>
>>> Yes, and it is still not enough for having 100% certainty that
>>> libbitcoin consensus code is functionally identical to other nodes'
>>> consensus code.
>>> All I was saying here is than even libbitcoin depending on
>>> libconsensus only for tests would be something good.
>>>
>>>> I'm not arguing for a libconsensus replacement, just pointing out that
>>>> comparative testing is not an integration scenario.
>>>
>>> Sure, and I was just saying that since there's no test vectors that
>>> can cover all cases, running random test against libconsensus would
>>> increase the testing surface.
>>
>> If some subset of tests change on each run, and the code changes as well
>> (otherwise why retest?) then we have added a moving window of tests over
>> a moving window of code. Granted this is an informal analysis, but you
>> could just as easily fix your randomly-generated tests and changing code
>> will likely cover the same increased surface.
>
> 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.

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

>> Also, in order to be useful test results need to be repeatable, which
>> means there is a new requirement to be able to recover the random test
>> vectors for any run.
>
> Of course you will be able to reproduce any random tests that fails.
> When testing libsecp256k1 by comparing its results with openSSL's on
> random tests, one of the random tests failed, just once.

I did not say it was impossible or even difficult to do, I said that it
would introduce an additional process requirement. Test process would
need to capture the randomly-generated state/seed of test runs.

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

>>> I agree. Hopefully will get there but a previous step is isolating all
>>> the consensus code within bitcoind (decoupling it from other
>>> functionality).
>>
>> Yes, and this underscores my point. Once you pull it apart, move
>> libconsensus to it's own repo, and expose only the VerifyScript call,
>> you will find that you have had to maintain a significant portion of the
>> code that implements VerifyScript in both bitcoin and in libconsensus.
>
> 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?

> So I think your complain is that libbitcoin will have some code
> duplication from libconsensus.

Not just some, a very significant portion.

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

> Since libbitcoin has much
> more functionality than libconsensus it will have to maintain much of
> its current script code, because users of libconsensus need to
> produce scripts.
> Depending on libconsensus would only save libbitcoin reimplementing
> the consensus checks, in this case only verifyScript (the script
> interpreter).
> Anything else will have to be maintained if libbitcoin wants to
> preserve its current functionality.
>
>> And it makes little sense for other libraries to use it if you don't.
>
> Mhhmm, I guess we agree to disagree here.

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.

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

e