Fix install error on Python 3.12

[giahuy98]

Running pip install -r requirements.txt on Python 3.12 fails due to leveldb using the removed PyUnicode_AS_UNICODE macro:

      /usr/include/python3.12/ceval.h:132:37: note: declared here
        132 | Py_DEPRECATED(3.9) PyAPI_FUNC(void) PyEval_InitThreads(void);
            |                                     ^~~~~~~~~~~~~~~~~~
      aarch64-linux-gnu-g++ -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -fPIC -I/home/ubuntu/tmp/opentimestamps-server/.venv/include -I/usr/include/python3.12 -c leveldb_object.cc -o build/temp.linux-aarch64-cpython-312/leveldb_object.o -I./leveldb/include -I./leveldb -I./snappy -I. -fno-builtin-memcmp -O2 -fPIC -DNDEBUG -DSNAPPY -pthread -Wall -DOS_LINUX -DLEVELDB_PLATFORM_POSIX
      leveldb_object.cc: In function ‘int pyleveldb_str_eq(PyObject*, const char*)’:
      leveldb_object.cc:795:33: error: ‘PyUnicode_AS_UNICODE’ was not declared in this scope; did you mean ‘PyUnicode_AsUCS4’?
        795 |                 Py_UNICODE* c = PyUnicode_AS_UNICODE(p);
            |                                 ^~~~~~~~~~~~~~~~~~~~
            |                                 PyUnicode_AsUCS4
      error: command '/usr/bin/aarch64-linux-gnu-g++' failed with exit code 1
      [end of output]

leveldb also appears unmaintained. Replaced it with plyvel in requirements.txt, which is maintained and compatible.

[petertodd]

Thanks!

I'm curious, are you actually using opentimestamps-server in production for something?

Honestly, I'm a bit reluctant to merge this as we don't really have good enough tests to catch a bug in plyvel; while python-leveldb is unmaintained, it has been working fine for years. I'm working on rewriting the opentimestamps server entirely in Rust, so hopefully I can finish that before actually needing this pull-req.

[giahuy98]

I'm curious, are you actually using opentimestamps-server in production for something?

Yes, I plan to run opentimestamps-server with a custom config to support faster transaction timestamping (for internal use).

Honestly, I'm a bit reluctant to merge this as we don't really have good enough tests to catch a bug in plyvel; while python-leveldb is unmaintained, it has been working fine for years. I'm working on rewriting the opentimestamps server entirely in Rust, so hopefully I can finish that before actually needing this pull-req.

Totally understandable. Looking forward to the Rust version. Thanks for the update!

[petertodd]

Yes, I plan to run opentimestamps-server with a custom config to support faster transaction timestamping (for internal use).

Faster timestamping on Bitcoin? Or on a different chain?

[giahuy98]

On Bitcoin, I assume passing --max-pending 1 lets the server create and broadcast a tx right away.

[petertodd]

On Bitcoin, I assume passing --max-pending 1 lets the server create and broadcast a tx right away.

Nope. --max-pending 1 does the opposite actually: it would only allow one commitment per timestamp transaction, making timestamps take extraordinarily long to confirm. The purpose of that option is actually to limit total RAM usage, by capping the maximum size of the merkle tree.

If you want fastest timestamp confirmations possible you actually want to reduce the --btc-min-tx-interval from the default.

But a better option would be to use the public calendars and donate funds so we can do faster timestamps for everyone. Do you have a consistent need for quick timestamps? Or is it something you need periodically?

For example, one option could be to use Lightning or something similar so that you can just pay the calendars to do a transaction immediately.

[giahuy98]

Got it, thanks for the clarification! I have a consistent internal need, so running a local calendar makes sense. I’ll think it over and explore the options.

[petertodd]

@giahuy98 FYI on my todo list is to also add a feature to the calendar to allow an upstream calendar to be used for the actual timestamp transactions, with the local wallet only used as a backup. This isn't a simple feature to add, so it'll take awhile. But in your case it'd let you, e.g. pay us to timestamp more frequently, with your own calendar as a backup if that doesn't work for some reason.