0.96 preliminary testing

[achow101]

The server=1/RPC cookie issue

If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow

Since the RPC stuff is now handled by the DB side, I imagine there's something that makes it difficult for an error on the DB end to trigger an error on the client end, although I am not sure. I can take a look and see if I can do anything about it this weekend.

[Carlton Banks]

Right, but the front end and the back end talk to each other. I guess it's a question of which you prefer, taking the time to change the code, or fielding alot of users getting the same problem in the subforum.

If even droark isn't clued in enough to picked it up straight away, I'd predict ~ 75% of users will be wailing about it without checking the pre-existing 12+ frontpage threads here describing the same issue.

[droark]

Have you guys tested the compressed P2SH keys on testnet? Any problems? I'd quite like to begin using them, it seems incredibly anti-social to continue to use uncompressed keys if their implementation is considered safe to use now.

Both nested script types have been tested on the testnet. I cross compiled 0.96 for my RPi yesterday and will test the nested compressed key script on the mainnet with my own coins sometimes before I post the first testing builds.

Any news on this?

Just now saw this. I've done a few transactions on testnet. Nothing thorough by any means but no problems on my end, other than the fee code being a bit screwy for awhile. (I believe it was cleared up awhile back.)

It takes something like 20-30 seconds to shut down on my machine, even though the CPU isn't active for most of that time. Of course, it's an improvement over 0.95, where it never shut down, period.

This is still (imo) the FCGI lib taking a while to shutdown. Again, you can try to profile that stuff. Here is a list of all the threads that need end for the process to exit gracefully:

Thanks. Will look when I get a chance.

[goatpig]

No real rush, like I said, I'd just prefer to start using compressed keys for everyone's sake. On that note, will compressed keys become the default key chain in the new wallets? And nested P2WPKH subsequently? I'm hardly expecting a no, I'm just wondering if you think that might cause an issue I'm not seeing.

There are 2 separate code paths for this:

1) Requesting payment addresses. This defaults to P2PKH. I did not add an option to change the default in the settings dialog, I'll have to deal with it eventually.

2) Change addresses. If left on auto, the code will try to match the spend script type. If all spend scripts are P2PKH, it will create a P2PKH change output and vice versa. When pay script types are mixed, auto will favor nested change types. In case of a SW tx, it will favor nested SW, otherwise nested P2PK.

This helps privacy at the cost of converting to compressed keys (or eventually SW) by default. You can however force the change type default to whatever you want in the setting dialog. You will receive a warning about reduced privacy if your change type differs from the pay script type however.

The drawbacks are 2 fold:

You cannot sign for nested types with pre 0.96 signers, and you can't expect to see your funds by simply importing the private keys in another wallet software and expect to see the balance of the nested scripts. These probably don't scan for these P2SH variations. I will most likely mitigate that by offering disgruntled users an opportunity to scan their wallets against my DB on demand, to create a tx and move their coins out in one sweep.

The scroll bar magic (that traverses super long balance lists) becomes stuck if I try to get beyond a certain proportion of the balance entries.

I'm just clicking, holding the click, and dragging the bar all the way to the base of the bar's range.

This doesn't trigger the Qt signal for hitting the end of the list until after you release the bar. I'm not sure where to get the signal for that event (if there's even one). I was aware of that limitation when I wrote this code but the cost of just figuring out how to get a signal off of the scroll bar is too high to bother as it is. It may appear lazy, but I settled for the model's signal, which won't trigger until after user input is completed. Hence is works by releasing the scroll bar, just using the arrows, or rolling the mouse scroller.

If the absence of server=1 can be detected, why not get Armory to produce an Error dialog box to tell the user how to deal with the issue? As I said, there'll be infinity threads about this if it's not handled at the software end somehow

I will eventually report the RPC status in the bottom right corner tooltip overlay. I don't intent to leave the bug there to begin with, it shouldn't prevent the DB from setting up.

[goatpig]

I can't reproduce the server=1 issue, can someone lay out the exact steps?

[Carlton Banks]

Do you mean that 0.96 connects the DB to the wallet without server=1 ? What sorcery is this?

[goatpig]

It does, whether the RPC works or not. The particular issue with the messed up cookie file is due to how the config file works with the testnet. When running against the testnet, Core still uses the .conf in the mainnet datadir to init, but will create the cookie file in the testnet datadir.

[bvoid]

Goatpig is it possible to upload the Armory_0.96_win64.exe (beta) on the website? I can't transfer my coins because of the "the broadcast process failed unexpectedly" bug. Thanks!

[goatpig]

Goatpig is it possible to upload the Armory_0.96_win64.exe (beta) on the website? I can't transfer my coins because of the "the broadcast process failed unexpectedly" bug. Thanks!

I understand your predicament but I can't yet push code that I don't believe is production ready. While you can build the code from source by pulling the dev branch, I am sorry but you will have to wait for signed binaries from me.

Hopefully I'll have a test build out tomorrow. Otherwise, sometimes next week.

[goatpig]

Pushed RBF.

Everything under the hood works. The GUI is rudimentary however. Basically it does not yet sort out corner cases like RBF -> CPFP -> RBF.

By design, conflicts between RBF and CPFP outputs are side stepped: CPFP and RBF are mutually exclusive. However, this isn't represented the GUI yet, which is the other part that needs polished before the UX is acceptable.

As it stands, you can:

- CPFP any eligible output correctly.
- Create RBF transactions
- CPFP an replacable output (say the change to your RBF spend)
- RBF any eligible RBF output. However conflicts are not handled: you can for example pick a replaceable output from one tx and a replaceable output from a child tx to the first one. This is a conflicting set of outputs. The GUI does not implement conflict detection and handling yet, but the Tx will obviously be invalid.

Once conflicts are handled the GUI, the code will be ready for testing releases. ETA Monday or Tuesday.

I have no yet tested spending from nested scripts on the mainnet, so please stay away from these until I risk my own money with them first.

[Carlton Banks]

Builds, but dies before ArmoryDB launches with this:

Code:

  def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(ERROR) Traceback (most recent call last):
  File "ArmoryQt.py", line 5848, in <module>
    checkForAlreadyOpen()
  File "ArmoryQt.py", line 5829, in checkForAlreadyOpen
    from armoryengine.ProcessMutex import PySide_ProcessMutex
ImportError: No module named ProcessMutex

Traceback (most recent call last):
  File "ArmoryQt.py", line 5848, in <module>
    checkForAlreadyOpen()
  File "ArmoryQt.py", line 5829, in checkForAlreadyOpen
    from armoryengine.ProcessMutex import PySide_ProcessMutex
ImportError: No module named ProcessMutex

[goatpig]

I'm an idiot, forgot to push a file. Should work now.

[Carlton Banks]

All is well.

What's the purpose of the RBF button on the Send form? I'm getting no addresses in the fields, whether I tick the RBF checkbox or not. Needs wallet 1.35c, or compressed keys? Or a different setting? (in Core maybe?)

[goatpig]

It works like the coin control dialog, but only lists RBF outputs. For an output to be listed there you need to

1) Create a transaction with the RBF option checked.
2) Have the transaction broadcast successful. All redeemed outputs should show in the RBF dialog.

I guess I should rename the button to have it convey that meaning. The idea is that RBF and coin control are mutually exclusive (since coin control also lists CPFP outputs, and these will more often than not conflict with RBF outputs).

If there is a demand for RBF to work with coin control, I'll look into that improvement in a later release.

[Carlton Banks]

Why not make it more direct? i.e. Right click eligible zero confs in the main tx window, a new (and probably simpler) dialog handles the fee bumping.

Presumably bumping the fee on some inputs and not others is meaningless, as all inputs are children of the overall parent transaction, for which there is a single fee applied for every byte? Makes sense to me, especially now that age-related priority is deprecated and on it's way to retirement.

[goatpig]

Why not make it more direct? i.e. Right click eligible zero confs in the main tx window, a new (and probably simpler) dialog handles the fee bumping.

There will be an option to do that eventually but for now RBF is an expert feature.

A bit of reasoning:

1) A sole bump fee feature hinges on a few assumptions that won't be met half the time. If the user expects to be able to bump fees off of the ledger, it supposes all transactions are RBF by default. I do not intent to do this. RBF will remain an opt-in feature in Armory, and off by default. I will most likely allow people to change the default in the settings, and consider adding a warning message on low fee transactions to turn on RBF. But I won't just force the thing on.

2) As a result, the whole bump off of the ledger part will be confusing. Either users will never use it (they would work with the outputs directly instead), or they turn to rely on the feature but end up confused when they fail to RBF.

3) RBF is not the only way to "pull in" a transaction. CPFP can be used to that effect as well, albeit for a higher fee at the cost of more block space. I want to let people have the choice, which would mean implementing a "pull transaction" option to the fee bump feature. Not that I think it's a bad idea, but now there is a lot of extra GUI to implement, and I don't want to pigeon people into a single feature as a way out.

4) How do I signal a transaction is eligible for replacement in the tx ledger? There is only so much room in the comment column (and text only gets you so far), nor is it very feasible to flash colors per line in these ledgers, and even that doesn't evidence what to do to bump the tx. Ideally a button just showing up on the particular line named "bump me!" would do the job. But I'm not sure the ledger model allows anything but text to be returned as entries to an index, so I can't go into this with a guarantee I can implement the model.

5) Most importantly, I cant skip the coin control like RBF GUI, because it is the only way to cleanly evidence RBF entries in a zero conf chain, and which child zc gets knocked off by a replacement. And also because at its core RBF is a double spend feature, so it should be usable in that way. It's not my place to figure out how that will be useful, but Armory is a wallet for advanced users, so it shouldn't curtail people to a narrow UX. Given that this UI has to go in either way, I have to do it first.

And before you argue this stuff won't happen, RBF is a fringe feature to begin with. You do not need this during regular operations, only when crazy stuff like a wild spam spike appears or the chain is being attacked, or you are trying to taint coins after a chain split. Who knows how convoluted things can get then. This is why RBF should be snafu proof from the get go.

[Carlton Banks]

The way I imagined it was:

Maintain the opt-in checkbox on the Send form, and create an overridden/inherited version of the right-click contextual menu that only presents "RBF" option for those transactions for which the opt-in had been stipulated in the Send form.

I think I see what you're getting at with chains of zero-confs though, but is it not the case that doing it as I describe would force the user in such circumstances to figure out for themselves which dependent tx is holding the others up? i.e. it would force the user to take responsibility for setting their own fees, and discourage bad practices, like creating chains of dependent tx's with insufficient fees?

Would making it easier in one way, yet making it harder feature to discover and understand in others, achieve less abuse of the RBF feature in practice?

[achow101]

Every couple of hours, ArmoryDB disconnects and reconnects to my Bitcoin Core node for some reason. It hits a StopBlockingLoop exception in processDataStackThread but I am not sure why.

I am running a build of Bitcoin Core's development branch, so it may be possible that something was changed for the next version of Core that is causing this error to occur. If that is the case, then this needs to be fixed so that we don't get a repeat of the "transaction timed out" errors.

I put it in gdb and let it run until that exception was thrown. Here is the backtrace of when gdb stopped at the exception being thrown (I think this is the right place for it to stop):

Code:

#0  0x00007ffff78c58bd in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00000000005db046 in BlockingStack<std::vector<unsigned char, std::allocator<unsigned char> > >::terminate (
    this=0x7fff9c000930, exceptptr=...) at ThreadSafeClasses.h:894
#2  0x00000000005d0891 in BitcoinP2P::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr) const (__closure=0x7fff980008c0, socketdata=std::vector of length 0, capacity 0, ePtr=...)
    at BitcoinP2P.cpp:995
#3  0x00000000005d3a4a in std::_Function_handler<bool(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr), BitcoinP2P::pollSocketThread()::<lambda(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)> >::_M_invoke(const std::_Any_data &, <unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecb9d>, <unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecba2>) (__functor=..., 
    __args#0=<unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecb9d>, 
    __args#1=<unknown type in /home/andy/bitcoin/BitcoinArmory/ArmoryDB, CU 0xa74053, DIE 0xaecba2>)
    at /usr/include/c++/5/functional:1857
#4  0x0000000000626085 in std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)>::operator()(std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr) const (this=0x7fffa3ffee30, __args#0=std::vector of length 0, capacity 0, __args#1=...)
    at /usr/include/c++/5/functional:2267
#5  0x000000000061fd72 in BinarySocket::readFromSocketThread(int, std::function<bool (std::vector<unsigned char, std::allocator<unsigned char> >, std::__exception_ptr::exception_ptr)>) (this=0xbb77d0, sockfd=2147483647, 
    callback=...) at SocketObject.cpp:378
#6  0x000000000061f301 in BinarySocket::<lambda()>::operator()(void) const (__closure=0x7fff9c000b58)
    at SocketObject.cpp:216
#7  0x0000000000625958 in std::_Bind_simple<BinarySocket::readFromSocket(SOCKET, ReadCallback)::<lambda()>()>::_M_invoke<>(std::_Index_tuple<>) (this=0x7fff9c000b58) at /usr/include/c++/5/functional:1531
#8  0x00000000006255f6 in std::_Bind_simple<BinarySocket::readFromSocket(SOCKET, ReadCallback)::<lambda()>()>::operator()(void) (this=0x7fff9c000b58) at /usr/include/c++/5/functional:1520
#9  0x000000000062547a in std::thread::_Impl<std::_Bind_simple<BinarySocket::readFromSocket(SOCKET, ReadCallback)::<lambda()>()> >::_M_run(void) (this=0x7fff9c000b40) at /usr/include/c++/5/thread:115
#10 0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x00007ffff7bc16ba in start_thread (arg=0x7fffa3fff700) at pthread_create.c:333
#12 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[johnlu]

Hi goatpig. I know 0.96 will be released when it is ready 
Do yo have an estimated date? I know you wouldn't like to commit to a shipping date or so. I just ask this to know how the roadmap is going through.

Thanks for your support and efforts for the community! :-)

[achow101]

Hi goatpig. I know 0.96 will be released when it is ready 
Do yo have an estimated date? I know you wouldn't like to commit to a shipping date or so. I just ask this to know how the roadmap is going through.

Thanks for your support and efforts for the community! :-)

The first testing build should be out today. Goatpig just bumped the version numbers and yesterday he told me he was going to release the first testing binaries today.