I know you've been wanting to get back to that. I'm travelling later
this week so my time is tight too.

There's also boost/multiprecision/cpp_int:

http://www.boost.org/doc/libs/1_55_0/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/cpp_int.html

and boost/multiprecision/gmp:

http://www.boost.org/doc/libs/1_55_0/libs/multiprecision/doc/html/boost_multiprecision/tut/ints/gmp_int.html

The latter looks better:

"It acts as a thin wrapper around the GMP mpz_t to provide an integer
type that is a drop-in replacement for the native C++ integer types, but
with unlimited precision."

And:

"Although this type is a wrapper around GMP it will work equally well
with MPIR. Indeed use of MPIR is recommended on Win32."

MPIR is what I'm using in the Windows builds.

e

On 05/13/2014 03:49 AM, Amir Taaki wrote:
> Copying back to list.
>
> Sure, if you want to take this on it's fine but it's more than I can do
> atm. I want to focus now on the blockchain stuff.
>
> On 13/05/14 12:42, Eric Voskuil wrote:
>> Sure, but also consider there is a downside of taking too much code
>> directly from bitcoind. I would be less hesitant if it was from another
>> source (and if it was a smaller class).
>>
>> Copying the test data should ensure compatibility, and I have more faith
>> in the correctness of GMP than bitcoin's equivalent. In the case of an
>> error in this code it would probably be a break they have to fix, not
>> something that we would want to match.
>>
>> In terms of maint, we already have the GMP dependency so we would not
>> have to maintain that code - a team of experts does that. If we take
>> from bitcoind we own it, and there will be drift, which means
>> maintenance. Our wrapper should be about the same in either case.
>>
>> e
>>
>> On 05/13/2014 02:57 AM, Amir Taaki wrote:
>>> The flip side is that copying that uint256.h means bug for bug
>>> compatibility, less work and less maintenance cost.
>>>
>>> On 13/05/14 11:56, Amir Taaki wrote:
>>>> We could also do that.
>>>>
>>>> Here are some unit tests we could copy:
>>>>
>>>> https://github.com/bitcoin/bitcoin/blob/master/src/test/uint256_tests.cpp
>>>>
>>>> On 13/05/14 11:50, Eric Voskuil wrote:
>>>>> Why not use GMP (which we already have as a dependency via secp256k1)?
>>>>>
>>>>> e
>>>>>
>>>>> On 05/13/2014 02:19 AM, Amir Taaki wrote:
>>>>>> We want to replace the remaining usage of big_number which is used in a
>>>>>> few places for calculating work (comparisons, basic arithmetic).
>>>>>>
>>>>>> I'm thinking to copy uint256.h over from bitcoind:
>>>>>>
>>>>>> https://github.com/bitcoin/bitcoin/blob/master/src/uint256.h
>>>>>>
>>>>>> to include/bitcoin/utility/external/
>>>>>>
>>>>>> and then make a custom wrapper in include/bitcoin/utility/
>>>>>> which implements a subset of that class which we require.
>>>>>>
>>>>>> Probably called 'hash_number' which is a descriptive name of this class.
>>>>>> Another possibility is pow_number (pow = proof of work, not prisoner...)
>>>>>> Or even proof_of_work_number?
>>>>>>
>>>>>> #include <bitcoin/utility/hash_number.hpp>
>>>>>>
>>>>>> Then after it's a few small steps to remove elliptic_curve_key,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>