AutoCove-Plugin VS bitcoin-verde

Electron Cash, since it has plugins. CashFusion's an example (internal plugin). I've released a couple external ones for fun (VanityTXID & AutoCove). A plugin can do anything if people edit the qt.py file inside the .zip.

Here is the hex if anyone wants to see it in AutoCove: 5479009c637cb1755479a9537a88537a011f7f7c01177f7b01197f00cc537a819d00cd537a8851cc7c819d51cd87777777675479519c63c3529d00c7827701179d00c700c658807e51c7827701199d51c6021027a26951c751c602b0049458807e7ea900c651c6930258029401147b7ec101157f777e00cc7b9d02a9147ca97e01877e00cd886d6d755167547a529d00cca1690376a9147b7e0288ac7e00cd8777776868

You could've used 2* OP_CODESEPARATOR. The pReturn... v1.1.0 Script I released today for AutoCove has 18% lower fee with a CODESEPARATOR. Here is the RefreshTimer hex to decode in Electron Cash v4.2.6:

Electron Cash has dark theme, too, but it has some color issues. I've released a plugin (AutoCove) that toggles B&W backgrounds, with colored Script. I dunno if the Android version of EC has the dark theme.

I've released an update to AutoCove (EC Script plugin) with asm & dark-theme support, an op-counter and TXID lookup. However it still needs another update.

The plugin's GitHub has the AutoCove-Plugin.zip needed to install it into Electron Cash. I last posted a video of v1.0.3 decoding some popular Script types. That version was missing Native Introspection & OP_REVERSEBYTES. The decoder now accepts whole raw txn input, and spelling can seamlessly switch between OP_CODES & codes etc.

For anyone interested, here is an auto-decode from State 52's pay-out (I need to think about the formatting):

I last posted after v1.0.2 introduced color. v1.0.3 can be downloaded from GitHub here. After someone spends from any address starting with p or 3, the Script hex can be copy-pasted from block explorers into the plugin, so that the Script is made more readable, e.g. with colors. It could be a nice way to check how smart contract plugins etc work, inside Electron Cash.

OP_RETURN could provide an elegant way to make automated payments. The contract address can auto-pay the receiver after a particular time (e.g. weekly rent payments). We need at least one node to query all OP_RETURNs to keep track of all new contracts. The auto-payment can be made using PrivKey=1. I've been developing AutoCove, but it's not powerful enough.

The v1.0.2 release is at GitHub. The .zip can be installed into any EC wallet, to play around with OpCodes. I'm really not sure what the colors should be. On the one hand, lines can start with green since that means go, but on the other hand the start of a line is when we have to stop & think about them. Then I wonder how next year's OpCodes will be colored...

AFAIK Verde has been releasing this for months now. (git).

Fair enugh, there is no formal proposal for consensus rules for UTXO commitments. That would be the next step if continuing from this proposal (as mentioned several times in the doc): https://github.com/softwareverde/bitcoin-verde/blob/development/specification/utxo-fastsync-chip-20210625.md

Verde: https://bitcoinverde.org / https://github.com/SoftwareVerde/bitcoin-verde/releases/tag/v2.2.0 (v2.2.0)

utxo commitments for real scaling

For now, the most obvious answer is to make the node reconsider the block for processing. Unfortunately, that script wasn't added to the latest release, but I've added it to our development branch. You can download it here: https://github.com/softwareverde/bitcoin-verde/blob/development/scripts/rpc/reconsider-block.sh . Despite the script not existing in the latest release, the node does support the RPC call, we only failed to include the convenience script.

Bitcoin Verde 2.1.0 has a feature