PixelCircuits

It could also be helpful to include an `_AMOUNT`, `_ASSET_ID` and `_TO` for `OutputChange` and `OutputVariable` for completeness. The bridge predicate already has a use case to check for `GTF_OUTPUT_CHANGE_ASSET_ID`

In Ethereum, EOA vs contracts is determined by looking if there is code at the given address. I know we can't do this in Fuel, but we could look at...

Can't an EOAs `Address` be a predicate hash? How would we force a bit in that scenario without breaking the ability to verify the predicate script? Would we just accept...

Would we have any issues with hardware wallets now? Were we supporting any fancy cryptography features (multisigs, multiparty computation, etc) that could break from this? Just trying to think of...

Can we add support for getting the hash of the script bytecode? I've been using this in the current predicate for the bridge: ``` use std::constants::ZERO_B256; const GTF_SCRIPT_SCRIPT_LENGTH = 0x005;...

> > Can we add support for getting the hash of the script bytecode? > > @pixelcircuits I'm not opposed to this. Would you mind opening a separate issue to...

This PR should wait until #2810 is finished since there is a lot of overlap

This PR is looking good. I just wanted to point to the [tests on my now defunct branch](https://github.com/FuelLabs/sway/blob/38317cac5c0a58f2a9a7174db7dbac2586efc06a/test/src/sdk-harness/test_projects/tx_fields/mod.rs#L340) for testing things like predicate bytecode and data when you get to...

Can we go ahead and use this issue to make all GTF_ const definitions public (`pub`) so that they can be referenced for more lower level solutions like the current...

This issue is now covered by #2707 since there was so much overlap