Skip to content

Conversation

luke-jr
Copy link
Member

@luke-jr luke-jr commented Oct 11, 2020

By moving the --with-bignum=no option to the start of the configure args, users can explicitly override it when configuring Bitcoin Core.

When this option was originally added in 2015 (7fd5b80 #6210), there was mention of a runtime crash reported by gmaxwell. Do details of that incident exist anywhere? Was it ever resolved? Did it crash at startup? If not, could it be triggered remotely?

@DrahtBot
Copy link
Contributor

DrahtBot commented Oct 11, 2020

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

@laanwj
Copy link
Member

laanwj commented Oct 14, 2020

The reason for disabling gmp by default is that the releases should not have a dependency on gmp. There are some good reasons to have the default configure options equivalent (or as close as possible) to the release options. Especially for something that affects consensus so directly if there was a bug in this less-tested path.

Concept ACK on being able to override it on demand though.

@fanquake
Copy link
Member

Can you clarify why this needs to be moved? Using master (661fe5d) I can do:

./autogen.sh
./configure --with-bignum=gmp
....
  asm                     = x86_64
  bignum                  = gmp
  ecmult window size      = 15

and secp256k1 is configured with bignum support using gmp. I guess there's somewhere this doesn't currently work?

@sipa also mentioned on IRC:

2020-10-11T16:16:27 luke-jr: fwiw, after secp256k1 PR 767 we'll probably remove bignum support entirely

@gmaxwell
Copy link
Contributor

gmaxwell commented Oct 15, 2020

This is going to be removed, so I don't think it makes sense to worry about it.

I don't know if it would be correct to say GMP to be maintained in a way suitable for consensus consistency: Although GMP testing is extremely good, they would-- for example, quickly fix a bug that slipped through in a minor release where consensus code might want to be handled in a more coordinated manner. (Although the secp256k1 GMP actually double-checks the GMP computation and will runtime assert for an incorrect result with 100% confidence, though if a GMP bug causes memory corruption all bets are off).

Use of GMP also potentially has licensing implications for users/redistributors as GMP is LGPLv3/GPLv2.

As far as the crash-- I don't recall and don't have access to old IRC logs, it's extremely likely that it would have been discussed in public. It would have been debian on PPC64 (big endian).

@luke-jr
Copy link
Member Author

luke-jr commented Oct 24, 2020

@fanquake No idea how you're getting that...

$ ./configure --with-bignum=gmp
...
  bignum                  = no

@luke-jr
Copy link
Member Author

luke-jr commented Oct 24, 2020

Rebased

@laanwj
Copy link
Member

laanwj commented Nov 19, 2020

This is going to be removed, so I don't think it makes sense to worry about it.

I think that alone is enough reason to not do this, let alone the other reasons you mention.
NACK

@luke-jr luke-jr closed this Nov 19, 2020
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants