Topic: 0.96 preliminary testing (Read 6363 times)

Binaries are not committed to the source code, they are not source code. You can can get the 0.96 testing binaries from https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.99.1-testing

I don't understand the question

No exe's in the test branch?

Testing builds are out, moved the code to the testing branch. Dev will be unstable again soon. Unsticking this thread.

Tested the compressed key script on the mainnet. RBF too. So far so good.


Usually, honest users don't try as hard to get things to work as malevolent ones. You are better off making the thing easy to use in the end. But UX is a pain to work on, so in due time.

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.

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! :-)

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):

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?

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.

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.

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.

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?)

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

Builds, but dies before ArmoryDB launches with this:

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.

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 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!

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.

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

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