+1

Awesome.

Very nice!

But in the "probably not your fault" category, it crashes on my OSX machine calling the openssl BN_bin2bn function:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00000000296707cc

VM Regions Near 0x296707cc:
--> 
    __TEXT                 0000000107e1d000-0000000107e1f000 [    8K] r-x/rwx SM=COW  /usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libcrypto.0.9.8.dylib           0x00007fff93af4446 BN_bin2bn + 118
1   _ctypes.so                      0x00000001087d47c7 ffi_call_unix64 + 79
2   _ctypes.so                      0x00000001087d4fe6 ffi_call + 818
3   _ctypes.so                      0x00000001087d070b _ctypes_callproc + 867
4   _ctypes.so                      0x00000001087cab91 PyCFuncPtr_call + 1100
5   org.python.python               0x0000000107e31ad7 PyObject_Call + 99
6   org.python.python               0x0000000107eade7f PyEval_EvalFrameEx + 11417
7   org.python.python               0x0000000107eb16d1 fast_function + 262
8   org.python.python               0x0000000107eae553 PyEval_EvalFrameEx + 13165
9   org.python.python               0x0000000107eaafb4 PyEval_EvalCodeEx + 1387
10  org.python.python               0x0000000107e4fbf5 function_call + 352
11  org.python.python               0x0000000107e31ad7 PyObject_Call + 99
12  org.python.python               0x0000000107e3c962 instancemethod_call + 174
13  org.python.python               0x0000000107e31ad7 PyObject_Call + 99
14  org.python.python               0x0000000107e78f2d slot_tp_init + 64
15  org.python.python               0x0000000107e746e7 type_call + 182
16  org.python.python               0x0000000107e31ad7 PyObject_Call + 99
17  org.python.python               0x0000000107eade7f PyEval_EvalFrameEx + 11417
18  org.python.python               0x0000000107eaafb4 PyEval_EvalCodeEx + 1387
19  org.python.python               0x0000000107eaaa43 PyEval_EvalCode + 54
20  org.python.python               0x0000000107eca816 run_mod + 53
21  org.python.python               0x0000000107eca8b9 PyRun_FileExFlags + 133
22  org.python.python               0x0000000107eca3f9 PyRun_SimpleFileExFlags + 711
23  org.python.python               0x0000000107edbe09 Py_Main + 3057
24  libdyld.dylib                   0x00007fff950c25c9 start + 1

OS Version:            Mac OS X 10.10.4 (14E46)
Code Type:             X86-64 (Native)

Probably the same issue:
petertodd/python-bitcoinlib#30

@gavinandresen Unfortunately, I haven't made any progress on fixing this. I can reproduce it on OS X, as well as on my own Arch Linux dev box, but not on Debian.

On Arch I can get it to work by compiling python from a tarball (instead of using the version from arch's package manager), so I think it's a problem with python/ctypes, and not something weird in the code or libssl.

It does seem to be the same issue as petertodd/python-bitcoinlib#30

It might be a good idea to still merge this, assuming it works on travis and for people not on OS X, so we can start building up a good series of block acceptance tests.

While I love the idea of ditching the existing comparison tool, rewriting it as-is seems like a very bad idea. The existing one is very hard to work with in large part because of the way the tests are generated - it's one big monolithic step-by-step. It really needs to separate out into something where individual tests are in individual functions/modules/whatever. Obviously running the tests in one run is probably the only way you can get it to run in reasonable time, but please don't duplicate the existing code.

On August 7, 2015 10:10:51 PM GMT+02:00, Casey Rodarmor [email protected] wrote:

@gavinandresen Unfortunately, I haven't made any progress on fixing
this. I can reproduce it on OS X, as well as on my own Arch Linux dev
box, but not on Debian.

On Arch I can get it to work by compiling python from a tarball
(instead of using the version from arch's package manager), so I think
it's a problem with python/ctypes, and not something weird in the code
or libssl.

It does seem to be the same issue as petertodd/python-bitcoinlib#30

It might be a good idea to still merge this, assuming it works on
travis and for people not on OS X, so we can start building up a good
series of block acceptance tests.

---

Reply to this email directly or view it on GitHub:
#6523 (comment)

A drop-in replacement in a more accessible language and format that behaved equivalently would seem to be a net win.

Sure, but if you're gonna go to the effort to rewrite it, might as well rewrite it better instead of transliterating a very fragile monolithic chunk of code.

On August 10, 2015 5:10:39 AM GMT+02:00, Jeff Garzik [email protected] wrote:

A drop-in replacement in a more accessible language and format that
behaved equivalently would seem to be a net win.

---

Reply to this email directly or view it on GitHub:
#6523 (comment)

"might as well" is in the eye of the do-er... In the absence of someone coming along and doing an even better rewrite, an incremental net-win should not be blocked because it lacks perfection :)

Agree with @jgarzik. I think that just having a python version available will lower the barrier for extra tests using it.

+1
utACK.
Travis did run this test successfully (https://travis-ci.org/bitcoin/bitcoin/jobs/74625657#L3538).

I just pushed changes which should fix the crashes on Arch and OS X.

Tests successful on OSX, ACK from me.

@casey FWIW I just ported those fixes to python-bitcoinlib: petertodd/python-bitcoinlib#77

Needs rebase after #6509 (Fix race condition on test node shutdown)

Rebased onto master.

Retested to verify that the OSX crash has been fixed.

In the future, please don't make changes to interfaces that quietly and subtley break things. In this case, create_coinbase's first argument changed meaning while quietly taking the same values and not throwing an error (or maintaining the previous functionality). As a result, I spent time trying to figure out why the CLTV RPC test failed on 0.11.2 when it had nothing to do with CLTV. :(