New Hampshire Budget Phases Out Income Tax Two Years Ahead of Schedule

https://www.atr.org/new-hbudget-puts-new-hampshire-a-year-ahead-of-schedule-to-become-next-no-income-tax-state/

A near-evenly divided New Hampshire House passed a budget on Thursday that significantly speeds up the phase out of the state’s tax on investment earnings, setting up the Granite State to become next no-income-tax state in less than 18 months – on January 1, 2025.

The new budget, expected to be signed quickly into law by Governor Chris Sununu, puts New Hampshire two full years ahead of schedule on its current plan to phase out the 4% interest and dividends tax by 2027. Tennessee repealed a similar version of this tax, known as the Hall Tax, in 2021.

“Our priority is to put our constituents first and give them the necessary tools needed to truly live the way they see best,” remarked Speaker of the House Sherman Packard, a Republican from Londonderry. “We don’t need to raise taxes or fees to do that. This budget makes that clear.”

Okay I see, there are packages that depend on the exported copy of bsv and therefore we must break support for that in order to move forward.

And you are sure it is necessarily the case that clients using this internal bsv module will stop working when we publish this new release?

In order to be a breaking change clients will have to be forced to modify their code in some way.

What modifications will be required by clients in order to upgrade to the boostpow-js v2?

If there are modifications required we should document them and if there are not modifications required then this should be a patch release not a major release.

Scrypt Design Considerations

From the Scrypt Discord Channel

Many design decisions I have made without reference to anyone else in scrypt and would like to coordinate on some concepts going forward for better cross-app compatability of objects.

For instance when assigning ownership to an object (instance) what should be the standard name of the prop for ownership?

When using a PubKeyHash to assign ownership the simple demo from the website names that prop p2pkh but I have gone back and forth and have decided to name that owner instead.

Similarly for when ownership is indicated by a PubKey I still am using the prop name owner that way anyone indexing the objects can create a database of objects owned by a given player, irrespective of the contract class because there is a standard owner property.

Also are people using PubKeyHash or PubKey more to assign ownership? It seems unnecessary to use PubKeyHash for objects that are called multiple times since the public key is going to be exposed anyway whenever you sign. Plus most known wallets only allow a single public key anyway for use with scrypt so re-use is an issue. Certainly for simplicity it is easier to use PubKey but should PubKeyHash be the standard approach? I am not clear. Of course using PubKeyHash would allow for people to securely mint, receive, and store objects with a unique address generated for each object by and extended (HD) private key, therefore never exposing any public keys until the contract was called.

Looking for pros and cons and perhaps most importantly any approach others are taking and what success, barriers you are facing.

VERSIONING: Another rather unresolved engineering challenge we are facing is how to version contracts. Has anyone approached trying to explicitly version their objects? Once deployed into a production-ready app it seems like these contracts are set in stone, so up-front design becomes incredibly critical. Versioning could help improve the release and feedback cycle on software development.

FEES: How is the most correct way to set sats/kb fees ? TAAL recently announced 0.001 sat/byte or 1sat/kb but scrypt-ts still charges 50 sat/kb by default!

REGISTRY: Has there been consideration for registering SmartContract classes on the blockchain so that the entire network may discover, download, and interact with all objects? A standard approach that embeds both the contract source code plus ABI metadata into a known data structure will enable us to create indexes on top and construct a library of known contract artifacts that can be consumed at one's leisure. Currently the whatsonchain contract verification tool does something like this but it is unclear if they are indexed the contracts, and that database is certainly not published on chain.

Yes there are many applications that can operate correctly with the sub-second latency bitcoin currently offers. Focus should be there.

Also it would be pretty sweet to have microcontrollers with native built-in support for connecting to TAAL and signing data with ECDSA keys.

Many controllers now can connect directly to MQTT for example, and bitcoin could be effectively swapped out as a message transport layer.

The controller could also contain a tamper-proof module for securing private keys and generating signatures.

Is most PLC data coming out entirely un-signed? I would assume signing is not yet normal.