refactor: adapt to btck_api changes and reorganize codebase

[alexanderwiederin]

Refactor: adapt to btck_api changes and reorganize codebase

Adapts to C API changes from bitcoin/bitcoin@bce88ae

API Changes

• Update enum variants to PascalCase (REGTEST -> Regtest)
• Remove UnownedBlock, replace with Block in validation callbacks
• Add user_data_destroy callbacks for proper memory cleanup - Rust now transfers ownership of callback data to C library

Code Organization

• Add constants.rs with btck_* constant definitions
• Move enums and verify logic to separate modules
• Improve type conversions and error handling

Platform Support

• Add Windows-specific library linking (bcrypt, shell32)

Next steps as follow-up to this change

• Further breakdown of lib.rs into separate files

Note: Changes should come more piecemeal from now hopefully

[TheCharlatan]

I think I'd prefer if we split the modules by their meaning, and not their type. In rust I would expect a module called "enums" to not necessarily hold enums, but define common traits for working with our enums. Is your plan to just park them there for now and then split them out into more files? I saw that you made an exception for the verification and think that would be a more coherent approach.

The callbacks will also require more work eventually. I wonder if passing in this single struct is really the best way to achieve this, or if we can come up with a clever set of traits that we can define for it.

[TheCharlatan]

How did the windows CI pass without these present so far?

[alexanderwiederin]

Looking into this.

[alexanderwiederin]

Do you know of any changes to how library dependencies are resolved in the build environment?

The library has always used Windows APIs that require these libraries (evidenced by bcrypt already being linked in the kernel's CMakeLists.txt), but something changed in how static library dependencies are handled between kernelApi_56 and kernelApi_60.

Any ideas? I couldn't find anything.

[alexanderwiederin]

I was unsure of how to deal with the enums, since they really are just thin wrappers around what is defined in the C API.

Anyways, had another thought about it and agree we should strive for a more purely domain-oriented structure (which I think you alluded to):

src/
├── lib.rs
├── ffi/                      # Foreign Function Interface / C bindings
│   ├── mod.rs
│   ├── c_helpers.rs          # Utilities for C callback patterns (incl. c_serialize, cast_string)
│   └── constants.rs          # C-side constants
├── core/                     # Core Bitcoin data types and consensus logic
│   ├── mod.rs
│   ├── block.rs              # Block, BlockHash, BlockSpentOutputs, TransactionSpentOutputs
│   ├── transaction.rs        # Transaction, TxOut, Coin
│   ├── script.rs             # ScriptPubkey 
│   └── verify.rs             # Script verification logic, flags, ScriptVerifyStatus ScriptVerifyError
├── state/                    # Chainstate & contextual info
│   ├── mod.rs
│   ├── chainstate.rs         # ChainstateManager
│   ├── context.rs            # Context, ContextBuilder, ChainType
│   └── chain.rs              # Chain, ChainIterator
├── notifications/            # Callback interfaces for notifications
│   ├── mod.rs
│   ├── kernel.rs             # KernelNotificationInterface callbacks
│   ├── validation.rs         # ValidationInterface callbacks
│   └── types.rs              # SynchronizationState, ValidationMode, BlockValidationResult, Warning
└── util/                     # Utility modules
    ├── mod.rs
    └── logging.rs            # Logger, LogLevel, LogCatgeory and Logging helpers (e.g. disable_logging)

The callback traits you mentioned could live in the respective files under /notifications.

Open to feedback on this approach. What do you think?

[TheCharlatan]

The layout you proposed looks closer to what I had in mind. I would call util/ just log.